Tcl/Tk, error handling, Perl Conference

[Steven E. Brenner]

Dear Georg,

  Regrettably, my travels (travails) are not yet at an end -- I was in
England last weekend and am visiting Yale and Columbia now.

  However, the timing of your message is good.  I recently had some very
practical experience which left me with little doubt about what we should
do when some error occurs.

  We should die().

  The advantages of dying are many, but the main one  which I see is that
the exception automatically is propagated upwards and can be dealt with at
any level.   With the code I had written extracted data from some 3
gigabytes of compressed files, and took about 4 hours to run.
Unfortunately, some of the files were corrupted, which caused the lowest
level routines to die.

  I was able to deal with this by having a high level routine simply look
for an exception and then move on to the next file if there were a
problem. 

  Using some sort of return-value system would have required every level
of the system to handle the error message from the lowest level.  To
faithfully report the error message, it would be necessary to have an
hugely increasing number of special error reporting singals.  

  The other major advantages of die() are that the return value can be
used to provide useful informatin rather than just a measure of success,
and that return values need not be continuously queried for
success/failure.   Further, the die() makes it clear to the user that
something has gone wrong, while poorly-written code would not do so.


  The principal disadvantage of die(), as discussed previously, was the
concern that huge programs would die() mid-way through, when in fact they
could have muddled on.  My experience suggests that trapping the exception
is actually easier than dealing with error return values.  

Steve