[Dbix-class] wishlist: exceptions

Mark Hedges hedges at ucsd.edu
Thu Mar 30 21:32:26 CEST 2006


I never know what I'm doing wrong.  I just get an undefined value
from methods.  Was nothing found?  Is the relation broken?  Where
did it break?  I do things in eval { } and I get no $EVAL_ERROR.

(Am I supposed to look at some old-school style package variable 
for errors?)

These are good reasons to use exceptions.  I am pretty happy 
with Exception::Class, which has some features over Error.  
It takes a change of mindset to start programming like:

    eval {
        # ...
    }; 
    if (my $X = Exception::Class->caught('My::X')) {
        $X->rethrow();
    }

... in lots of subroutines where things could break, but doing this:

    My::X->throw('dumb message');

in the even of an error lets you trap for any My::X (or 
subclasses) at some top level call (like a Mason autohandler -- 
incidentally, Mason uses its own Exception::Class hierarchy).  
Then it stringifies very nicely with an optional stack trace.  
And you can add fields to them, for instance, 'sql', 'values', 
and 'errstr' is one I use to trap DBI errors in, then I have it 
splice the values into the SQL at ? bind locations before it 
prints.

Exceptions are a core feature of lots of other languages.
As a perl coder you have to force yourself to implement them.

Mark



More information about the Dbix-class mailing list