--- On Fri, 9/4/10, Aristotle Pagaltzis <[email protected]> wrote:
> From: Aristotle Pagaltzis <[email protected]>
> Why?
>
> I guess that could be addressed by allowing a hash of
> formats and
> then offering the throwing site to pick one of them by
> setting
> a special field.
>
> The key here is that you want to avoid a situation where
> catching code has to parse the error message.
Buuuuuut ... that's why you want those exceptions in classes instead of as hash
keys. For example (Javaesque psuedo-code):
try {
customer.read();
}
catch ( Exception::IO::NotFound e ) { ... }
catch ( Exception::IO::CantOpen e ) { ... }
catch ( Exception::IO::CantRead e ) { ... }
catch ( Exception::IO e ) { ... }
catch ( Exception e ) {
panic("I don't know what type of exception I have!" . e);
}
Yeah, the example is overkill :)
The point here is that you try more specific exceptions first and drill down to
less specific ones, including a "catch-all" exception. However, what happens
if you get rid of the "NotFound", "CantOpen" and "CantRead"? If the exception
thrown is one of those types and assuming they're really subclasses of
Exception::IO, then the "Exception::IO" catch will catch them rather the
incorrectly falling through to the panic. If these were merely shoved in a
hash, you'd have to try to fall back to parsing either the messages (or the
key) to figure out that you don't really have a panic.
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
