Oppolzer - Informatik / Blog

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

PL1-L - Merkwürdige Fehler im Zusammenspiel mit PL/1 und C (ON ERROR)


Re: ON ERROR GOTO ... ??


Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>


PL1 (language) discussions <PL1-L@LISTSERV.DARTMOUTH.EDU>


2012.06.21 18:44:24

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
> 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).
> ...
> here he called for example a function to get rid of some of the storage !!
> ...
> END;
> CALL math_library;
> ...
> 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

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

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie