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

I've been musing over how to report errors from a module I'm writing. Specifically, when to issue warnings and when to throw exceptions (warn vs. die, or better Carp::carp vs. Carp::croak). There are various ways of doing this: Each of these options has its disadvantages (somewhat exemplified by the italicised comments), be it that they are (respectively) too strict, not strict enough and confusing

So, I'm now making this behaviour configurable. Something like (for an OO inspired module): 

package Foo;
# ...
do_tricky_stuff or $self->_complain("Tricky stuff failed");
do_unrecoverable_stuff or return $self->_complain("Grave problem");
# ...
sub _complain {
  my $self=shift;
  my $msg=shift;
  croak($msg) if $self->fatal_warnings();
  carp($msg);
  return undef;
}

[download]
This allows for exceptions (everything is an exception) or recoverable / non recoverable warnings (non recoverable return undef), depending on the (user settable) value of an instance attribute.

I'm looking for some input on how other people handle this.

CU
Robartes-

Replies are listed 'Best First'.
•Re: Error reporting in modules
by merlyn (Sage) on Apr 15, 2003 at 12:33 UTC
    Although the exception handling of DBI is considered by some to be a bit overdesigned, I would consider it as a model. There are global variables to provide defaults about whether to die, warn, or simply return flag values on every call. Then there are per-database-handle overrides for those, and per-statement-handle overrides for those again. I've found it to give me the flexibility I need for the style I want to to program in today.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
Re: Error reporting in modules
by Abigail-II (Bishop) on Apr 15, 2003 at 12:36 UTC
    Perl already has a fine mechanism to have the user determine whether warnings should be generated or not (the warnings module). Then you don't have to set an attribute for each object (and what would you do in a function that didn't get an object as one of its arguments?).

    I'd say, throw a warning (using warnif) if there's a sensible way to continue (say, you can use a default). And die if you can't. A die can always be caught by the caller, so if the caller sees a way to continue, the caller has that option.

    Abigail

[reply]
[d/l]
[select]
Re: Error reporting in modules
by l2kashe (Deacon) on Apr 15, 2003 at 14:05 UTC
    This was a useful thread which asked the same basic question.

    MMMMM... Chocolaty Perl Goodness.....
[reply]
Re: Error reporting in modules
by cLive ;-) (Prior) on Apr 15, 2003 at 17:09 UTC
    My rules are currently along the lines of:

    If value is unexpected, but harmless, return warning

    Eg, if sub is expecting to receive a number (including 0), but receives an empty string, assume number is zero, but warn anyway.

    If valid value is necessary to continue, die

    Eg: 

    open(LOG,"<logfile") || die "Can't read log file for parsing - $!";

    [download]

    exceptions

    I have a bunch of sudo scripts that have to be very locked down. I expect the calling script to know exactly what it's doing. If it doesn't I assume there's some bad juju going on and die - even if it could technically continue.

    I also use a trace through caller() to help with debugging, but that's another issue :)

    cLive ;-)

[reply]
[d/l]

Back to Seekers of Perl Wisdom