From: David Nicol <davidni...@gmail.com>
>
>To: publiustemp-moduleautho...@yahoo.com
>
>I've never understood what's wrong with using string exceptions for this kind
>of thing. Maintaining a discipline about properly dieing is required both
>ways, and
>
> defined ($nextline = <INPUT>) or die "IO CANTREAD: eof on INPUT?"'
>
>seems more concise than abstracting an exception type hierarchy behind a class
>hierarchy only to unabstract it later:
>
> eval {
>> $customer->read(); 1
>> } or do {{ # double openers to create block to last out of
>> my $e = $@;
> $e =~ m/^io notfound/i and do { ...; last };
>
> $e =~ m/^io CantOpen/i and do { ... ; last };
>> $e =~ m/^io CantRead/i and do { ... ; last };
>> $e =~ m/^io /i and do { ... ; last };
> die "$e UNEXPECTED"; # filename, line number, newline added by die
> }};
>
Using string matching on exceptions is bad because if a developer wants to
"clarify" an error message, they might rewrite it, only have have the exception
handling not match it. Plus, when I was working on Bricolage, we had
localisation of exception messages. If you had a non-English locale, those
exceptions would *never* have matched. However, since we matched on exception
class rather than exception text, we didn't have to worry about it.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://blogs.perl.org/users/ovid/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
