Non-Trappable Error

When an exception occurs, it is desirable that your application caters for it in a professional manner. That is the application shouldn’t just disappear and provide no clues to the user what has gone wrong. I covered how you can handle this in an earlier Ask Reuben article.  There are a class of errors where this is not always possible and these are called non-trappable errors.

Whilst it would be desirable that all errors can pass through your exception handling routine, for these non-trappable errors it is not safe or desirable to allow the fglrun process to continue.  When a non-trappable error occurs, the following will occur …

1. In GUI, display a pop-up window with the error.
2. If STARTLOG has been previously called, write an error record to the log file.
3. Print the error message to stderr (when running through GAS, these will appear in the vm log.)
4. Stop the program.

Even though your exception handling may do something similar, there is no limit to the code that could be executed in the function called by your WHENEVER ANY ERROR CALL or after a WHENEVER ANY ERROR CONTINUE, and this may impact in the decision making on why it is not safe to allow the runner to continue.

The documentation of non-trappable errors gives a list of error numbers that are non-trappable, and the individual error documentation will have a note indicating that it is non-trappable.  To help understand why these are non-trappable errors, consider these examples and ask yourself the following questions …

-1320 – A function has not returned the correct number of values expected.   If the runner was allowed to continue, what would happen to the extra value returned, is it left on the stack?,  or what would happen to the last variable ready to receive a variable that does not receive anything, would it be set to NULL?.

-1326 -An array variable has been referenced outside of its specified dimensions.  If the runner was allowed to continue, what value would you expect to see used in an expression involving the array variable?   Is there potential an assignment would impact the adjacent areas in memory?  (For this error, there is an fglprofile entry that will allow the runtime to continue but I think that hides something that is wrong with your code, and you would be better off identifying what is wrong with your code and fixing it so the exception does not occur.)

-6107 – User limit exceeded. Please retry later.  What would happen if the runner was allowed to continue when you had exceeded your license count?

For a number of these you might be able to construct a scenario where you might think it is safe to continue but we have to consider the worst case.

I would suggest you experiment and note the output you get from a trappable error in your code and a non-trappable error.   A simple trappable error is to do a divide-by-zero e.g. DISPLAY 1/0, LET i = 1 /0.  A simple non-trappable error is use the 0 index in an array e.g. DISPLAY arr[0], LET arr[0] = 1.  Your first-level support should be able to identify when a non-trappable error has occurred so that if they see a dialog similar to …