Tcl/Tk, error handling, Perl Conference

[Steve A. Chervitz]

SteveB writes:

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

I am under the same conviction here: die()ing is the only way to ensure 
that errors get noticed and dealt with (or deliberately ignored).  

Recently, I've changed how error handling works in my Obj:: modules
to incorporate Perl's built-in die()/eval{} system with my own Err object. 
Basically, I added some methods to my core object that can either warn() 
or die() with the contents of my Err.pm object and also attach the Err 
object to the object throwing the exception to record the event, so 
that the object can be querried later about any exceptions it threw.

There are some nuances which I am still exploring, such as:
 * handling exceptions occuring within constructors,
 * allowing exceptions to invalidate an object (or not),
 * propagating exceptions up a containment heirarchy,
 * letting the object decide how strict to be about its errors.

It would be great if you could send an object reference in $@ upon 
die()ing. Then, an exception handler could examine the exception and 
decide if it wants to handle or re-throw it. This would permit true 
try-catch behavior.  

Any suggestions about how to make die() more object savvy (in contrast to 
making objects more die() savvy, which what I'm doing)? One idea I've 
been batting around is to re-construct the Err object from the $@ string, 
which consists of the contents of an Err object, but this seems 
inefficient and has some limitations. Sending objects in $@ would likely  
require fundamental changes in Perl. 

My modules can be viewed from my bioperl page:
http://genome-www.stanford.edu/~sac/perlOOP/bioperl

But be forwarned they are apt to change.


SteveC