[erlang-questions] Package Support/Use
Richard A. O'Keefe
Wed Nov 8 05:20:32 CET 2006
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.
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;
READ FILE(FRED) INTO(SOME_RECORD);
process the record;
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!
More information about the erlang-questions