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

(Strange... I think I submitted this node once. But since I can't see it here, I'll try to repost. Pardon me if i'm wrong :))

Let me try to help your ignorance ;-).

First, OO-ish style of error handling (where objects such as Error are involved etc.) is a concept easily understood by anyone who's ever sinned with any other language than Perl. I confess to having had a lot of dealing with Java (and continue to do so until even now) and C/C++. Therefore, dealing with similar (in terms of look and logic) error handling mechanism in Perl is something natural to me. It is not to say, however, that I lack appreciation for the good old eval/die construct. These are perfectly good in their own right.

Further, OO-ish approach allows for a number of other 'conveniences' (if I could put it that way...). To name a few, I could for example encapsulate error handling code inside an easy to understand/work with Error class. For example, i could write an Error class that would write to a special Log file and optionally even email certain party of interest (such as sysadmin...) on any error. Having tucked this into would also clear my main program code and make the main logic easy to understand. There also may be certain errors that might have to be handled in a particular way. For certain purposes creation of separate Error type classes is well warranted. Say, you could write an Error::DBIFail exception class to handle rall back procedures in case of a DBI fail (I know DBI may provide for a basic rallback mechanism... yet that may not always suffice the need).

I hope my ran was helpful? ;)

"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
  • Comment on Re: Re: Exception handling (alternatives)

Replies are listed 'Best First'.
Re: Re: Re: Exception handling (alternatives)
by impossiblerobot (Deacon) on Dec 22, 2001 at 03:24 UTC
    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
[reply]
      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