Oppolzer - Informatik / Blog

From: "Bernd Oppolzer" <bernd.oppolzer@T-ONLINE.DE>
Sent: Thursday, 21 June 2012 5:57 PM


> 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.

Normal behaviour for batch programs is to continue wherever possible, rather
than abort.

> 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.

It is perfectly normal to leave an ON-unit via a GO TO. In point of fact, it it
the only way to leave an ERROR ON-unit when continuation of processing is
desired.

> Furthermore, the short-on-storage condition will not be resolved,

Why not? You haven't said how storage is taken (ALLOCATE?). However taken,
storage can be released.

> and if new inputs
> are taken, new errors will occur. So the ERROR handlers will be nested
> on and on ...

ERROR handlers won't be nested on and on. As soon as GOTO exits an ERROR
handler, that ERROR handler terminates. Recall that an ON-unit is like a
procedure. When it terminates (even with GOTO), it terminates, full stop.

> or do I get something wrong?
>
> Or precisely: if there is a GOTO in an ON ERROR unit, how does LE handle
> this?

The ON-unit terminates (presuming that the GOTO transfers control out of the
ON-unit).

> 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.

It's the second error that is processed. The ON-unit, namely, GOTO, is executed.

> 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.

There is always additional work done when an ON-unit terminates.
Recall that it's like a procedure.

> 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; ...

That's perfectly normal.