Re: Re: The art of error handling

But if you return undef or 0, the error is unspecific, it just means there was a failure... how do you address the specifics? I have been struggling with error checking myself, so I am quite curious what responses will appear.

Update: By the way, the way that I have been handling errors in modules is to have a sub called error() which takes a string, stores it in an ERRORS array in the package, and return undef, so I can have code like this:

open(TEST, ">$file") or return $self->error("Failed to open $file");
[download]

That way, I get the undef return value, and store the error in the array in one shot. There's probably a few better ways, though.

Hot Pastrami

Comment on Re: Re: The art of error handling Download Code

Replies are listed 'Best First'.
Re: Re: Re: The art of error handling by mirod (Canon) on Dec 19, 2000 at 21:58 UTC
If you use subroutine/methods which perform simple operations then the calling code usually either ignores the error, fall back to another method (`$val= $obj->method \|\| default`) or dies quickly. So I usually handle errors at the level just above the method/subroutine where it happens. Not quite the "detect at the lowest level and at the highest level" philosophy, I admit, but it usually works for me.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: The art of error handling
by mirod (Canon) on Dec 19, 2000 at 21:58 UTC

If you use subroutine/methods which perform simple operations then the calling code usually either ignores the error, fall back to another method ($val= $obj->method || default) or dies quickly.

So I usually handle errors at the level just above the method/subroutine where it happens. Not quite the "detect at the lowest level and at the highest level" philosophy, I admit, but it usually works for me.

[reply]