Re: Advantages of OO-ish exception handling..

[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

[Masem]

You *could*, but that's not good programming practice (That is, you simply have all your functions declared as throwing generic Exceptions. The Java Exception model is designed that as your classes become more specialized, the types of exceptions they throw should also become more specialized. The only place were you should catch the base class of all exceptions, Exception, is in the main() body of the code or in the JApplet/JApplication object.

Note that you cannot throw a more generic exception type than your function/method allows. If FileException ISA IOException ISA Exception, then a function that defined itself to throw an IOException will be happy as long as only FileExceptions or IOExceptions are thrown, but will complain (AT COMPILE TIME, since the exception mechanism is that detailed) if you throw a generic Exception.

-----------------------------------------------------
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