OpenEdge ABL Phantom Error

November 30, 2007 · Filed Under Development, Reliability · Comment 

At Solvepoint we’ve coined a new term, the Phantom Error. What is a Phantom Error you ask? Well, it is an undesirable circumstance where the Progress VM decides to raise the error condition but leaves error-status:get-message() set to the empty string.

This , of course, can lead to a host of ugly sorts of bugs not the least of which is not having any idea where the error happened or why.

Here is a simple example that demonstrates a Phantom Error:

DEFINE NEW GLOBAL SHARED VARIABLE myHandle AS HANDLE NO-UNDO.
main: DO ON ERROR UNDO main, RETRY main:
  IF RETRY THEN do:
    MESSAGE RETURN-VALUE error-status:get-message(1) VIEW-AS ALERT-BOX.
    LEAVE main.
  END.
  RUN someProc IN myHandle.
END.

You’ll notice that both return-value and get-message(1) return blank.

If you happen to be in a terminal based procedure editor, however, you will receive the error message in the “message area” at the bottom. Unfortunately, this doesn’t do much good for server code.

As a consequence, server code will typically swallow these Phantom Errors at worst, or report the error out of context at best.

So, what can be done? Diligent error trapping is called for. Protect the code by always testing handles before using them.

Unfortunately, this isn’t the only type of code that will produce a Phantom Error. We will discuss other Phantom Errors under the Tag “Phantom Errors” in other posts.

Tags: , , ,