On Fri, Apr 9, 2010 at 1:54 AM, Ovid <publiustemp-moduleautho...@yahoo.com>wrote:
> (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. > 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 }}; Either way, you still need to maintain the meaning of the string prefixes or the various exception types in a project-wide data dictionary. I don't want to start (or restart) some kind of big argument; my understanding is that coders coming from a Java background simply prefer to use classes for everything.