[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