Oppolzer - Informatik / Blog

Thank you all for you suggestions so far.

I would like to add that in the first error handler (which sets of the ON ERROR
GOTO ENDE) there is a CALL to a function of the application which tries to do
some cleanup.

While thinking some more time about the problem, I guess, that the designer
tried to accomplish the following - well, let me first try to explain:

in my opinion, there should only be one error handler in the main routine. It
should capture the ERROR condition, write a dump, and terminate the process.
This should be normal behaviour in batch programs.

Now, in this case, my co-worker observed the short-on-storage condition in the
underlying C++ math library and he tried to catch this by coding this ON ERROR
unit and continue with the next input (I guess).

ON ERROR BEGIN;
ON ERROR GOTO ENDE;
...
here he called for example a function to get rid of some of the storage !!
...
END;

CALL math_library;

ENDE:

...

Now my idea is: there are additional errors in the function which tries to free
the storage, that is: inside the ON ERROR unit. If the ON ERROR unit is left
using GOTO, I don't know how LE behaves. We resume NORMAL PROCESSING using GOTO,
while in an ERROR handler. This does not seem sound to me.

Furthermore, the short-on-storage condition will not be resolved, and if new
inputs are taken, new errors will occur. So the ERROR handlers will be nested on
and on ...

or do I get something wrong?

Or precisely: if there is a GOTO in an ON ERROR unit, how does LE handle this?
ON ERROR GOTO ENDE - in my opinion this means that the error is ignored and
processing continues at label ENDE in case of an error. But if this is coded
inside an ERROR UNIT (or inside another block, specifying a label ENDE, which is
non-local), there has additional work to be done. In this special case, this
means, that in the case of an error TWO NESTED ERROR HANDLERS have to be exited
- the one that handles the ON ERROR GOTO ENDE and the embedding one, that
contains the ON ERROR BEGIN; ON ERROR GOTO ENDE; ...

could it be possible, that there is an error in the implementation??

It should be easy to confirm this, using a little test program.

Kind regards

Bernd




Am 21.06.2012 06:00, schrieb R.:
> From: J.B.
> Sent: Thursday, 21 June 2012 12:19 PM
>
>
>> The first ON ERROR block is intended to perform error handling for
>> the CALL
>> statement.  If the error handler fails, then the CALL statement is
>> bypassed
>> and execution proceeds by setting up a new error handler.  If an
>> error is
>> subsequently detected, the second ON ERROR block is invoked, at which
>> time
>> error intercepts are disabled by the ON ERROR SYSTEM statement,
>
> Strictly speaking, they aren't "disabled", but are replaced when
> the new ON statement [namely, ON ERROR SYSTEM]
> re-instates standard system action for the ERROR condition.
>
>> and an
>> failure in the error handler results in the termination of the program.
>
> Again, strictly speaking, only any errors that cause the ERROR condition
> to be raised.  Other errors that don't raise the ERROR condition
> will not be handled and (subject to any other ON statements for
> those kinds of errors) will pass.
>
>    If it is desired to catch any kind of error in the ON-unit,
> no matter how trivial,
>    ON ANYCONDITION ... should be used.
>
>    In the design of an error handler for the ERROR condition,
> after which it is intended to resume normal processing,
> the code needs to be kept short and simple, in order to
> minimise the chances of raising more conditions,
> including the ERROR condition again.
> Things like SUBSTR, and data conversions that might raise the
> CONVERSION condition, should be avoided.
>
>> This approach is both common and good design.
>
> I like that observation.
>
>> I would consider it to be unlikely that the error handler setup is
>> the cause
>> of your problem.
>>
>> I do not recommend the removal on the ON ERROR units.  Rather, I
>> recommend
>> that "ON ERROR BEGIN" be changed to "ON ERROR SNAP BEGIN".
>>
>> J.B.
>