On Wed, 16 Jul 2003, John Siracusa wrote:

> Here's my take on handling parse errors, and error handling in general.
>
> 1. I don't like to (unconditionally) die from within libraries except for
> conditions that are totally avoidable.  For example, I die if you forget to
> send a required argument.  But I would not die in a parse() function that is
> expected to handle user-created input!  That would force everyone to use an
> exception-handling style of error checking just to use your modules, which
> is not nice.

Yeah, I can buy this, since parsing is inherently something that can fail,
and it often need not be fatal, because it doesn't indicate a usage error,
as opposed to bad parameters.

> 2. I use plain old undef as my error return value, but I sometimes document
> the methods saying that any false value is an indication that there was an
> error.  This works in all methods that return objects (which is most of the
> ones I write, and any parsing method in DT).

This also makes sense.

> 3. I make sure I store some sort of sensible error message or code somewhere
> convenient, letting the user of the library know why something failed.  Even
> if it's only "Invalid date: 'foobar'", it goes a long way towards making
> debugging easier.
>
> I think this system gives the most flexibility to the user of a library.
> Examples:
>
>     # Use fatal errors
>     $dt = DateTime->parse(...) or die DateTime->error;
>     $dt->parse(...) or die $dt->error;
>
>     # Use non-fatal errors
>     if($dt = DateTime->parse(...)) { ... }
>     else { warn DateTime->error }
>
>     if($dt->parse(...)) { ... }
>     else { warn $dt->error }
>
>     # Use exception handling
>     eval
>     {
>       $dt = DateTime->parse(...) or die DateTime->error;
>       $dt->parse(...) or die $dt->error;
>       ...
>     };
>
>     if(@$) { ... }
>
> Finally, I want to immediately help anyone who does this:
>
>     $dt = DateTime->parse(...);
>     $dt->set(...);
>
> By puking all over them right then and there.  While a "DT::Undef" object
> might be useful for some, it should not be used as a return value in the
> case of an error.  People who want to use it can just do this:
>
>     $dt = DateTime->parse(...) || DateTime::Undef->new;

I agree.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Reply via email to