Advantages of OO-ish exception handling..

[vladb]

In reply to my earlier node related to my cut at an OO-ish exception handling package, impossiblerobot had raised a series of deserving questions related to the need of using a OO-ish approach in place of an old and trusted eval/die mechanism for exception handling. Since (as usual) this innocent quest has led to a deeply nested thread (therefore hiding it from the praying minds of fellow monks) while leaving some questions unanswered (I've failed to handle them all on my own :), I thought it would be appropriate to repost the node here for general consideration.

So, the original question is (paraphrased from original question by impossiblerobot that could be found here):

What (other than making perl look like some other languages) does the use of OO-ish exception handling mechanism have over the normal Perl error-handling methods (eval/die)?

Also, is there any clear advantage of the OO approach other than the obvious "syntactic sugar"?

"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith

[Masem]

This doesn't apply to perl's OO-ish handling, but when I was programming in Java, I found that the nature of Java's forced exception handling made me think of the possible failure states of my code while writing and testing it, as opposed to an afterthought that came about in later stages of development. IMO, I'd rather do error testing with exceptions rather than eval-die, particularly if you have a potentally deep exception model.

(For those not familar with Java's exception handling, if your function or method calls any other function or method that is declared to return an exception, you must either catch that exception in your function, or declare your function one that can throw that type of exception. Exceptions were objects, so that allowed generic ("RuntimeException") as well as specific ("PermissionDeniesException") exceptions to be issued. Note that this differs from C++ as functions neither are declared to throw exceptions, and you don't have to deal with exceptions; you can let fail up through the call stack).

-----------------------------------------------------
Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

[jeffa]

If you are a pioneer for Perl6 or P5EE, then i can see the benefits of encapsulating error conditions into those glorified goto's known as exceptions. But otherwise, this just isn't needed in most day to day Perl scripts.

I have no reservations about using another language that actually has those keywords, like Python, Ruby (my new favorite leisure language) or even, ick, Java. And if Perl6 includes 'real' exceptions, then I will use them, but I try to stay true to the spirit of the language, and try-catch in Perl5 is about as useful to me as a switch block. But don't let me stop your quest, it is a noble one.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)

[impossiblerobot]

One of vladb's answers, which I agreed would be an advantage in many circumstances was the ability to pass the error-handling back up through nested structures to be handled by 'parents.'

But Masem seems to say that in Java you have to explicitly deal with those exceptions in some way (either explicitly 'catching' them, or explicitly 'throwing' them back up the chain), which seems to remove some of the advantages of having the ability to 'inherit' error-handling.

Of course, vladb's exception implementation doesn't have this Java limitation. But this concept put another twist on the issue (for me, at least). This may make sense in Java, but I can't seem to make sense of it in Perl. :-)

Impossible Robot

[Masem]

I don't want to pull out a Java book to demonstrate what I mean, but let's take this hypothetical case where I want to read a file that has a specific format. I can do the following (*code isn't correct, but the idea is there*) in Java:

class FileException inherits Exception { ... };
class BadFormatException inherits FileException { ... };
class IOException inherits Exception { ... };

// main code...
//
try {
    readDataFromFile( "file.dat" );
} catch ( FileException e ) {
    System.out.println("Something went wrong");
}

int readDataFromFile( String filename ) throws FileException {
// ...
    fileRef = openFile( filename );
    while ( data = readLine( fileRef ) ) {
        ...
    }
}

File openFile( String filename ) throws IOException { ... }

String readLine( File file ) throws BadFormatException { ... }

Note in this code, I don't have to worry about the error until the higher level calls in the main function, because all the functions that get called return exceptions that ISA FileException. If, however, readLine returned a different exception, I'd either have to make sure readDataFromFile also was declared to throw the same (or a parent of that) exception, OR add a specific try/catch block into that function as to remove that exception before it moves up the stack.

-----------------------------------------------------
Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

[impossiblerobot]

If I understand this right, I could throw a generic exception-type (possibly even the top-level exception class?) and thereby pass the exception-handling up the class hierarchy. Is that a fair re-statement?

I suppose this is not the place for a Java lesson (though it looks like I need one). But it does help me start to see how this type of structure might be useful in Perl.

(It still seems like a lot of hoops to jump through if this is the only benefit.)

Impossible Robot

[premchai21]

Inheritance. You can then test for the type of exception caught using isa (or its equivalent in whichever language you're using). This way, you can partition the set of possible exceptions into useful subsets, and deal with each subset individually.

[vladb]

Precisely!

And on top of it, you can do it at verious stages of your execution (aka layers). Some errors may have to be dealt with in lower levels (nearer to, says, system 'layer') and thus not visible to upper layers that shouldn't really be concerned with certain details.

isa() calls is certainly a great way to approach this. It is also much more clearer than dealing with static die strings ($@). Certainly, static strings, by their nature, do not allow for the complexity (i should rather say, flexibility) that OO offers.

On the other hand, it may be more justifiable to actually not use OO-ish excpetion handling methods in simple code and therefore avoid going through the 'extra hoops' in order to yield no noticable reward.





"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith