[Dbix-class] Re: Catching DBI errors, without eval?

Brandon Black blblack at gmail.com
Mon Nov 13 13:01:11 GMT 2006


On 11/12/06, Josef Karthauser <joe at tao.org.uk> wrote:
>
> Ok, I'm now connecting to the database as follows:
>
>         my $schema = __PACKAGE__->connect($DSN, $username, $password,
>             { PrintError => 0, RaiseError => 0 } );
>

Turning off RaiseError and/or using HandlError are not wise ways
forward, as future versions of DBIC might break your expected
behavior, or your code might break future versions of DBIC.

The throwing of exceptions on errors, as opposed to returning an
"error" value of some sort, is a code philosophy that pervades
throughout most modern perl development.  Throwing exceptions is
simply a better idea than trying to represent the existance of an
error and its details via return values and global variables and
whatnot.  In an ideal world, a method should either return exactly
what it was asked to return, or throw an exception.

If you expect your exceptions to be rare and unexpected, you can just
use a top-level eval over most of your code, and catch all fatal
exceptions there and do some logging and cleanup.  Frameworks like
Catalyst should catch them for you.

It's not really feasible for us to have any kind of argument or flag
that switches DBIx::Class over to a "signal errors via return values
and globals" model, as it would seriously muck up the code.

In the current development branch (0.07999_01 on CPAN is from that
branch), you can use $schema_thing->exception_action($coderef) to hook
your own code into our exception throwing.  The purpose there is to
give you a chance to wrap DBIx::Class errors in a special exception
object, especially one that might do stack tracing or whatever.

You could in theory make this coderef set a global error variable and
then return true to suppress the exception, and then check that error
variable manually after each call into DBIx::Class.  It will be ugly
and sub-optimal, but nobody's going to stop you :)

-- Brandon



More information about the Dbix-class mailing list