in reply to Re: Re: Exception handling (alternatives)
in thread Exception handling (alternatives)

Thanks, vladb. I understand that making the exception-handling look like other languages can increase the comfort level. But I still don't see the advantages over 'eval'ing and calling an error-handling subroutine (which could be separated from the main program and do the things you mentioned).

I'm not trying to be cantankerous, but as I attempt to increase my Perl skills (as well as possibly needing to learn Java soon), this seems to be an important issue.

Maybe it's just the fact that although I think I understand OO programming, I don't get it. :-)

Impossible Robot
  • Comment on Re: Re: Re: Exception handling (alternatives)

Replies are listed 'Best First'.
Re: Re: Re: Re: Exception handling (alternatives)
by vladb (Vicar) on Dec 22, 2001 at 04:18 UTC
    Perfectly valid concern! ;-). I actually very much enjoy our discussion.
    Let me add a few points then to leverage your understanding of the advantages involved.
    Yet another great advantage of OO-ish exception handling is be that different types of errors could be dealt with at different 'layers' of your code. For example, I might have a system exception in my code handled by Error::Sys. Such an error could be thrown but the inner-most subroutine and picked up and processed only a few levels up the call tree. (yet not at the very top of it... say at the main:: package). There may be a number of other exception types/categories that are only handled by certain layers of your code. In such case, OO-ish way is slightly batter compared to eval/die.

    Making same with eval/die would (if possible) be somewhat cumbersome (at least the way I see it :). In order to weed certain die messages at various layers of my code, I might have to institute a mechanism to make sure that every die message has a particular keyword in it. For example, for a system error I might have "SYSTEM: error text". Then, later in the code (or up the call tree), I'll check for a match with that key word. And if matched, I'll process it accordingly instead of leaving it to be handled by upper-layer code (sorry if my terms sound amusing :-> ..). With OO, you may simply do something like this: 
    # called from sub foobar() which in turn
# is called from foo() which in turn...
sub do_something {
... 
try {
    stuff();
} catch Error::Sys with {
        # handly any System error right here
};
# any other error will go up the call tree..

}

    [download]
    With eval/die similar code would have to be implemented as follows: 
    # called from sub foobar() which in turn
# is called from foo() which in turn...
sub do_something {
... 
eval {
    stuff();
};
my $err = $@;
if ($err =~ m/SYSTEM:/) {
        # handle any System error right here

} elsif ($err) {
    # any other error will go up the call tree..
    die $err; # rethrow
}

}

    [download]
    I'm sure there's tons of other examples that could be brought up. I hope that the ones I mentioned are reasonable ;-)
[reply]
[d/l]
[select]
      Thanks again, vladb. This makes sense to me. Although I think you could simplify the usage of the standard Perl error handling from your example, by the time you really made it easy, you would probably end up writing pretty much what you did in your exception-handling routine. :-)

      Of course, this need/advantage is closely tied to how the program is structured; using a paradigm where nested 'exceptions' and structures exist requires handlers for those exceptions, right?

      Impossible Robot
[reply]

In Section Meditations