in reply to How to subclass DBI and still have the errors reported in user code

use Carp qw(croak) # in your overrided method: eval { # call SUPER method here } if ($@){ croak($@); }
  • Comment on Re: How to subclass DBI and still have the errors reported in user code
  • Download Code

Replies are listed 'Best First'.
Re^2: How to subclass DBI and still have the errors reported in user code
by roman (Monk) on Sep 11, 2007 at 13:14 UTC

    Thanks for idea, it is the solution, but:

    With catch and croak you have to take care of context (AFAIK), something like this:

    sub selectrow_array { my $this = shift(); my ( @ret, $ret ); eval { if (wantarray) { # list @ret = $this->SUPER::selectrow_array(@_); } elsif ( defined(wantarray) ) { # scalar $ret = $this->SUPER::selectrow_array(@_); } else { # void - nonsense $this->SUPER::selectrow_array(@_); } }; croak $@ if $@; return if !defined wantarray; return wantarray ? @ret : $ret; }

    The original error line is still being reported. Of course you can strip it with RE. But with $dbh->{'PrintError'} set the line still appear.

    DBD::mysql::db selectrow_array failed: Table 'devel.no_such_table' doe +sn't exist at simple.pl line 17. DBD::mysql::db selectrow_array failed: Table 'devel.no_such_table' doe +sn't exist at simple.pl line 17. at simple.pl line 43

    DBI actually "croaks" for itself. The error is reported on the boundary of user and DBI code. What I want is to tell DBI: this code is safe, don't report errors from here, go up in stack. I dont' know whether DBI has some rules for telling whether a call shouldn't generate errors as Carp have (inheritance is one the rules).

    Maybe that the elegant, DBI specific solution, doesn't exist.