in reply to Re: Error Handling with Packages
in thread Error Handling with Packages

Returning the error as a second value is usually not a good idea. It requires too much discipline to always check the error status, after every call, and it doesn't allow for idiomatic checks as 
foo() or die "foo failed";

[download]
so lazy programmers will just don't do it resulting on the worst kind of errors: unnoticed errors!

Usually it's much better to croak(): module users would still be able to handle errors via eval if they wish, and when not, the final user will notice that something went wrong because the croak will reach them.

Replies are listed 'Best First'.
Re^3: Error Handling with Packages
by anjoschu (Sexton) on May 24, 2005 at 08:55 UTC

    I have another custom approach:

    Read more... (1323 Bytes)

    This way the module user can still use idioms like

    $O->foo() or die "could not blabla: ".$O->error();

    [download]

    Users can still set the error handler to croak() if they wish. This could be extended ad nauseam: $debug switches, $exec_handler switch, method to get errMsg without resetting it -- you name it. I should probably put it in its own module, too, and inherit from that. I'm still not sure how to escalate errors when one method calls another. Maybe simply

    sub bar {
    my ($self) = @_;

    foo() or return raiseError("bar failed to rhubarb: ".$self->error(
+));
    return 1;
}

# ...

$O->bar() or die "could not blabla: ".$O->error();
# "could not blabla: bar failed to rhubarb: foo: could not do thisandt
+hat"

    [download]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom