[erlang-questions] Package Support/Use

[Richard A. O'Keefe]

I should point out that my initial experience with exception handling
was in PL/I, where the original idea was that the system would set a
whole bunch of pseudo-variables, like ONSOURCE, which was the variable
that the system thought held the bad data.  You were expected to
*assign* to ONSOURCE and then *resume* the faulting statement.
My experience was that the only time I was ever able to "repair" the
error was when I had enough information to stop the exception being
raised in the first place.

Let's see,
    ONCHAR*	the character that caused a conversion to fail
    ONCODE	a number telling you what kind of error it was
    ONCONDCOND	the name of the CONDITION-type error as a string
    ONCONDID	one of (currently) 23 numeric codes, including condid_endfile
    ONCOUNT	the number of conditions not yet handled
    ONFILE	the name of the file that had a problem as a string
    ONGSOURCE*	like ONCHAR but for DBCS characters
    ONKEY	the key of the record that had an i/o problem, as a string
    ONLOC	the name of the procedure that had a problem
    ONSOURCE*	the field that caused a conversion to fail, as a string
    ONSUBCODE   a number with more detail about I/O errors
    ONWCHAR*	wide character version of ONCHAR
    ONWSOURCE*  wide character version of ONSOURCE

Note that ONFILE is an identifier, as a string, not an actual file you can
use.  Oh, and if you didn't want the faulting statement resumed, you had to
use a GOTO.  So

    ON ENDFILE(FRED) BEGIN GOTO FRED_ENDED; END;
    DO WHILE('1'B);
       READ FILE(FRED) INTO(SOME_RECORD);
       process the record;
    END;
FRED_ENDED:

I'm sure you will appreciate why I am so firmly convinced that end of file
should not be regarded as exceptional.

Curiously enough, while PL/I has a SUBSCRIPTRANGE condition -- not enabled
by default --, it does not give you an ONSUBSCRIPT feature to find out what
the bad subscript was.

How happy I am not to be using PL/I!