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.

Reply via email to