[Chicago-talk] A question of 'die'ing

[Al Tobey]

On 1/29/07, Shawn Carroll <shawn.c.carroll at gmail.com> wrote:
> What are your thoughts on a library that will die if it is given
> invalid input?  Would use such a library if it required you to put
> eval blocks around it each time?

I do it all the time for truly fatal errors.   My philosophy is "death
before corruption" when it comes to runtime data checking.

It is probably good style to document all of the exceptions (or at
least the "common" ones) that a given method can throw.   I think
Conway has a bit about that in PBP.   I usually put a bit in the POD
like: "This method will throw exceptions for bad parameters or no data
returned from the database."

People with better taste than myself might say that throwing an
unusually high number of exceptions indicates a flawed interface.
They're right.   For instance, the debate between implicit hashes for
named parameters and requiring a hashref - the hashref makes the
interface clear and gets you some better compile-time checking as a
bonus, while the implicit hash can have all sorts of problems when the
interface is abused.

$obj->new( thing1 => $val1, $val2 ); # compiles
$obj->new({ thing1 => $val1, $val2}); # doesn't compile

Another thing to question is whether the exception should be an
exception or an exceptionally well-tested part of the interface.
use Test::More;

As you said, the user can always catch the exception with eval.    You
might check out Exception::Class to provide an OO interface if you're
planning on throwing a lot of exceptions.  Test::Exception is handy
for making sure your exceptions actually work, too.

-Al Tobey
Grand Rapids Perl Mongers

>
> --
> shawn.c.carroll at gmail.com
> Perl Programmer
> Soccer Referee
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at pm.org
> http://mail.pm.org/mailman/listinfo/chicago-talk
>