jk2addict has asked for the wisdom of the Perl Monks concerning the following question:

I would like to implement error handling similiar to the way that DBI does in which the consumer of the modules can choose whether the module will Carp out errors, or just stuff them into an ->errstr() method and move on.

Of course, TIMTOWTDI.
I was thinking of AUTOLOADING /carp/cluck/croak/confess/ to either stuff the error locally, or shove it into Carp depending on some other config options.

Is there a better way to do this?

Replies are listed 'Best First'.
Re: Carp; errors ala DBI
by bart (Canon) on Sep 19, 2002 at 15:57 UTC
    Hmm... aren't you trying too hard? Can't you just do: 
    sub carp {
    if($should_i_stay_or_should_i_go) {
        require Carp;
        goto &Carp::carp;
    } else {
        # process locally
        ...
    }
}

    [download]
[reply]
[d/l]
Carp; errors ala DBI
by rir (Vicar) on Sep 19, 2002 at 22:10 UTC
    Please don't use AUTOLOAD in code for distribution , UPDATE, without using NEXT.
    Thanks to adrianh for correcting me.

    AUTOLOAD is a namespace hog living in the global namespace.
    Client code can't avoid your AUTOLOAD routine.

    In your case it is an inappropriate solution. You know
    the names of the routines you want to call.

    You might want to use a constant for config branching: 

     
use constant ERRSTR => 1;
if ( ERRSTR) {
    # errstr stuff
}else{
   # carp stuff
}

    [download]
    this will eliminate the unneeded branch at compile time.

    UPDATED: because I was behind times regarding existence of NEXT.

[reply]
[d/l]
      Please don't use AUTOLOAD in code for distribution.

      You must be kidding, don't you? :-)

      At least I saw two good modules which uses AUTOLOAD very well: CGI.pm and matts's DBIx::AnyDBD. CGI.pm uses it to delay compilation of certain subs - aka lazy compilation. In DBIx::AnyDBD, AUTOLOAD "inherits" DBI's database handles methods. At a glance, this is also doable by subclassing the DBI::db package. Dunno why matts chooses the AUTOLOAD approach instead of subclassing.

[reply]
        Yes, I am serious. Update: But use the relatively new NEXT and all the problems can go away.

        AUTOLOAD is a powerful and facile tool: a beautiful thing.
        I like it a lot. So there can be overriding motives to use
        AUTOLOAD, but if possible it is to be avoided by module
        publishers.

        It is a name greedy pig.

        The way Perl resolves a call is:

        1. Seek routine in package.
        2. If method: seek method in base classes.
        3. Seek AUTOLOAD in package.
        4. If method: seek AUTOLOAD in base classes.

        The following code demonstrates the problem. 

        #!/usr/bin/perl -w
use strict;

package Mumma;
use vars qw( $AUTOLOAD );
sub AUTOLOAD { 
    print "$AUTOLOAD resolved to Mumma::AUTOLOAD\n"; 
}

package Poppa;
use vars qw( $AUTOLOAD );
sub AUTOLOAD { 
    print "$AUTOLOAD resolved to Poppa::AUTOLOAD\n"; 
}

# Baby doesn't know that Mumma & Poppa are secret AUTOLOADERs
package Baby;
use vars qw( @ISA $AUTOLOAD );
@ISA = qw( Poppa Mumma );   # Order is significant. 
sub new { bless {}, ref $_[0] || $_[0] }

package main;
use vars qw( $AUTOLOAD);

# Baby is supposed to live in a caring universe.
sub UNIVERSAL::AUTOLOAD { 
    print "$AUTOLOAD resolved to UNIVERSAL::AUTOLOAD\n";
}

my $c = Baby->new();

# first &AUTOLOAD found hides rest.
$c->wants_mumma();
$c->wants_poppa();
$c->wants_universal_truth();

        [download]
[reply]
[d/l]

Back to Seekers of Perl Wisdom