(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 - mneylon-pm@masemware.com || "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

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)

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 { ... }
[download]

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 - mneylon-pm@masemware.com || "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

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

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.

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