www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Chaining exceptions

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Consider:

void fun() {
    try {
       throw new Exception("a");
    } finally {
       throw new Exception("b");
    }
}

Currently this function would unceremoniously terminate the program. I 
think it shouldn't. What should happen is that the "a" exception should 
be propagated unabated, and the "b" exception should be appended to it. 
The Exception class should have a property "next" that returns a 
reference to the next exception thrown (in this case "b"), effectively 
establishing an arbitrarily long singly-linked list of exceptions.

A friend told me that that's what Java does, with the difference that 
the last exception thrown takes over, so the chain comes reversed. I 
strongly believe "a" is the main exception and "b" is a contingent 
exception, so we shouldn't do what Java does. But Java must have some 
good reason to go the other way.

Please chime in with (a) a confirmation/infirmation of Java's mechanism 
above; (b) links to motivations for Java's approach, (c) any comments 
about all of the above.


Thanks,

Andrei
Nov 18 2009
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:


 Consider:
 
 void fun() {
     try {
        throw new Exception("a");
     } finally {
        throw new Exception("b");
     }
 }
 
 Currently this function would unceremoniously terminate the program. I 
 think it shouldn't.


Have you tried it?  I think the call to terminate() is commented out.  It was
like this before I ever started mucking with the runtime many moons ago.  What
I think currently happens is that the exception in the finally clause will
replace the one being thrown.  That or it's discarded, I really can't remember
which.  Either way, the current behavior is a bit weird.


 What should happen is that the "a" exception should 
 be propagated unabated, and the "b" exception should be appended to it. 
 The Exception class should have a property "next" that returns a 
 reference to the next exception thrown (in this case "b"), effectively 
 establishing an arbitrarily long singly-linked list of exceptions.


The Exception class already has a "next" property, but I've always seen this as
a way to nest exceptions.  For example:

try
{
    throw new Exception;
}
catch( Exception e )
{
    throw new MyException( e );
}

So a network API might throw a NetworkException that references a
SocketException with more detailed info about the exact problem, etc.  The
reason I'm unsure about chaining related exceptions as opposed to use chaining
as a means of repackaging exceptions is that the catch handler that ultimately
executes will be the one that matches the first exception in the chain, not the
first that matches any exception in the chain.  I haven't thought about this
too carefully, but it seems like it might be difficult to write correct code
with this model.


 A friend told me that that's what Java does, with the difference that 
 the last exception thrown takes over, so the chain comes reversed. I 
 strongly believe "a" is the main exception and "b" is a contingent 
 exception, so we shouldn't do what Java does. But Java must have some 
 good reason to go the other way.


When a dozen holes appear in a dike, I'm not sure it matters which one you try
to plug first :-)  Unless there's some way to start with the biggest one, I
suppose.  Seems like with the suggested model, the correct approach may be to
always catch Exception and walk the whole chain to figure out what to do.  But
that sounds awfully close to C-style error handling.
Nov 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Andrei Alexandrescu Wrote:
 

 Consider:
 
 void fun() { try { throw new Exception("a"); } finally { throw new
 Exception("b"); } }
 
 Currently this function would unceremoniously terminate the
 program. I think it shouldn't.


 
 Have you tried it?  I think the call to terminate() is commented out.
 It was like this before I ever started mucking with the runtime many
 moons ago.  What I think currently happens is that the exception in
 the finally clause will replace the one being thrown.  That or it's
 discarded, I really can't remember which.  Either way, the current
 behavior is a bit weird.


Guilty as charged. Haven't tried. I don't have D installed at work, but
I tried a Java example and indeed it looks like the last exception
thrown just takes over.

class Test {
     public static void main(String[] args) {
         System.out.println("Hello World!");
         try {
             (new Test()).fun();
         } catch (Exception e) {
             System.out.print(e);
             System.out.print(e.getCause());
             System.out.print("\n");
             e.printStackTrace();
         }
     }

     void fun() throws Exception {
         try {
             throw new Exception("a");
         } finally {
             throw new Exception("b");
         }
     }
}

Even more interestingly, calling printStackTrace() does not acknowledge
the originating exception. Calling getCause() returns null. So
essentially at the catch point I'm not sure there's a way to get to the
"a" exception.


 What should happen is that the "a" exception should be propagated
 unabated, and the "b" exception should be appended to it. The
 Exception class should have a property "next" that returns a 
 reference to the next exception thrown (in this case "b"),
 effectively establishing an arbitrarily long singly-linked list of
 exceptions.


 
 The Exception class already has a "next" property, but I've always
 seen this as a way to nest exceptions.  For example:
 
 try { throw new Exception; } catch( Exception e ) { throw new
 MyException( e ); }
 
 So a network API might throw a NetworkException that references a
 SocketException with more detailed info about the exact problem, etc.
 The reason I'm unsure about chaining related exceptions as opposed to
 use chaining as a means of repackaging exceptions is that the catch
 handler that ultimately executes will be the one that matches the
 first exception in the chain, not the first that matches any
 exception in the chain.  I haven't thought about this too carefully,
 but it seems like it might be difficult to write correct code with
 this model.
 

 A friend told me that that's what Java does, with the difference
 that the last exception thrown takes over, so the chain comes
 reversed. I strongly believe "a" is the main exception and "b" is a
 contingent exception, so we shouldn't do what Java does. But Java
 must have some good reason to go the other way.


 
 When a dozen holes appear in a dike, I'm not sure it matters which
 one you try to plug first :-)  Unless there's some way to start with
 the biggest one, I suppose.  Seems like with the suggested model, the
 correct approach may be to always catch Exception and walk the whole
 chain to figure out what to do.  But that sounds awfully close to
 C-style error handling.


Well I'm not sure about the metaphor. What I can tell from my code is 
that exceptions are often contingent one upon another (not parallel and 
independent). A typical example: writing to a file fails, but then 
closing it also fails and possibly attempting to remove the partial file 
off disk also fails. In that case, the important message is that the 
file couldn't be written to; the rest is aftermath. If the doctor says 
"You have a liver problem, which causes your nails to have a distinctive 
shape" you don't mind the nails as much as the liver.

There's also the opposite flow, for example an exception in some 
validation prevents a database update. But I don't think code regularly 
does essential work in destructors, finally blocks, and scope 
statements. The essential work is done on the straight path, and the 
important error is happening on the straight path. In fact, what I just 
wrote tilted me a bit more in favor of the "master exception + 
contingent camarilla" model. That model also suggests that most of the 
time you only need to look at the top exception thrown to figure out the 
root of the problem; talking to the camarilla is optional.


Andrei
Nov 18 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:


 Sean Kelly wrote:

 
 When a dozen holes appear in a dike, I'm not sure it matters which
 one you try to plug first :-)  Unless there's some way to start with
 the biggest one, I suppose.  Seems like with the suggested model, the
 correct approach may be to always catch Exception and walk the whole
 chain to figure out what to do.  But that sounds awfully close to
 C-style error handling.


 
 Well I'm not sure about the metaphor. What I can tell from my code is 
 that exceptions are often contingent one upon another (not parallel and 
 independent). A typical example: writing to a file fails, but then 
 closing it also fails and possibly attempting to remove the partial file 
 off disk also fails. In that case, the important message is that the 
 file couldn't be written to; the rest is aftermath. If the doctor says 
 "You have a liver problem, which causes your nails to have a distinctive 
 shape" you don't mind the nails as much as the liver.


Upon reflection, I'm inclined to agree.  This is pretty much a nonexistent case
for me anyway (my experience with C++ has me following the "no exceptions from
dtors ever" mantra for the most part), so it's difficult to come up with
counterexamples.  I also like that your chaining method represents a timeline
of what happened, with the most likely cause of the whole mess at the head of
the list.
 

 There's also the opposite flow, for example an exception in some 
 validation prevents a database update. But I don't think code regularly 
 does essential work in destructors, finally blocks, and scope 
 statements. The essential work is done on the straight path, and the 
 important error is happening on the straight path.


Yeah, I think you're right.
Nov 18 2009
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 18 Nov 2009 15:24:11 -0800, Andrei Alexandrescu wrote:


 Consider:
 
 void fun() {
     try {
        throw new Exception("a");
     } finally {
        throw new Exception("b");
     }
 }
 
 Currently this function would unceremoniously terminate the program. I
 think it shouldn't. What should happen is that the "a" exception should
 be propagated unabated, and the "b" exception should be appended to it.
 The Exception class should have a property "next" that returns a
 reference to the next exception thrown (in this case "b"), effectively
 establishing an arbitrarily long singly-linked list of exceptions.
 
 A friend told me that that's what Java does, with the difference that
 the last exception thrown takes over, so the chain comes reversed. I
 strongly believe "a" is the main exception and "b" is a contingent
 exception, so we shouldn't do what Java does. But Java must have some
 good reason to go the other way.
 
 Please chime in with (a) a confirmation/infirmation of Java's mechanism
 above; (b) links to motivations for Java's approach, (c) any comments
 about all of the above.
 
 
 Thanks,
 
 Andrei


Best as I can tell, the Java compiler doesn't do the chaining 
automatically. It is up to the one throwing the exception to make the 
chain. The exception class just provides a specification that requires 
all exceptions to support chaining. This explains why it is not the root 
cause that is at the head of the chain.

try {
     stmt.executeUpdate(sql);
} catch (SQLException ex) {
   throw new
   EmployeeLookupException(
   "Query failure",ex); // ex is passed to the constructor of the class
} 

Example from: http://java.sys-con.com/node/36579

http://www.developer.com/tech/article.php/1431531/Chained-Exceptions-in-
Java.htm
Nov 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jesse Phillips wrote:

 On Wed, 18 Nov 2009 15:24:11 -0800, Andrei Alexandrescu wrote:
 

 Consider:

 void fun() {
     try {
        throw new Exception("a");
     } finally {
        throw new Exception("b");
     }
 }

 Currently this function would unceremoniously terminate the program. I
 think it shouldn't. What should happen is that the "a" exception should
 be propagated unabated, and the "b" exception should be appended to it.
 The Exception class should have a property "next" that returns a
 reference to the next exception thrown (in this case "b"), effectively
 establishing an arbitrarily long singly-linked list of exceptions.

 A friend told me that that's what Java does, with the difference that
 the last exception thrown takes over, so the chain comes reversed. I
 strongly believe "a" is the main exception and "b" is a contingent
 exception, so we shouldn't do what Java does. But Java must have some
 good reason to go the other way.

 Please chime in with (a) a confirmation/infirmation of Java's mechanism
 above; (b) links to motivations for Java's approach, (c) any comments
 about all of the above.


 Thanks,

 Andrei


 
 Best as I can tell, the Java compiler doesn't do the chaining 
 automatically. It is up to the one throwing the exception to make the 
 chain. The exception class just provides a specification that requires 
 all exceptions to support chaining. This explains why it is not the root 
 cause that is at the head of the chain.
 
 try {
      stmt.executeUpdate(sql);
 } catch (SQLException ex) {
    throw new
    EmployeeLookupException(
    "Query failure",ex); // ex is passed to the constructor of the class
 } 
 
 Example from: http://java.sys-con.com/node/36579
 
 http://www.developer.com/tech/article.php/1431531/Chained-Exceptions-in-
 Java.htm


Thanks! Question - is there a way to fetch the current Throwable from 
within a finally clause?

Andrei
Nov 18 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:

 
 Thanks! Question - is there a way to fetch the current Throwable from 
 within a finally clause?


FWIW, I've been thinking about adding this feature for ages.  I think there's
even a comment to the effect in core.thread somewhere.  In short, I think we'd
need a thread-local field for storing the current exception.
Nov 18 2009
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 18 Nov 2009 18:27:47 -0800, Andrei Alexandrescu wrote:


 Thanks! Question - is there a way to fetch the current Throwable from
 within a finally clause?
 
 Andrei


I'm pretty sure you can't since finally isn't passed an exception. I also 
don't see anything in my quick search.
Nov 19 2009
parent reply BCS <none anon.com> writes:
Hello Jesse,


 On Wed, 18 Nov 2009 18:27:47 -0800, Andrei Alexandrescu wrote:
 

 Thanks! Question - is there a way to fetch the current Throwable from
 within a finally clause?
 
 Andrei
 


 I'm pretty sure you can't since finally isn't passed an exception. I
 also don't see anything in my quick search.
 


That stands to reason because in some cases (when things go correctly) there 
isn't one.
Nov 20 2009
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
BCS wrote:

 Hello Jesse,
 

 On Wed, 18 Nov 2009 18:27:47 -0800, Andrei Alexandrescu wrote:


 Thanks! Question - is there a way to fetch the current Throwable from
 within a finally clause?

 Andrei


 I'm pretty sure you can't since finally isn't passed an exception. I
 also don't see anything in my quick search.


 
 That stands to reason because in some cases (when things go correctly) 
 there isn't one.
 
 


One hopes.  Just the same: (hypothetical syntax incoming)

try {
	// ...
}
catch ( ExceptionA exa ) {
	// ...
}
catch ( ExceptionB exb ) {
	// ...
}
finally ( x ) {
	// ...
	if ( x ) throw new ExceptionC( x );
}

And obviously if finally has no () it doesn't bother with the feature.

-- Chris Nicholson-Sauls
Nov 20 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chris Nicholson-Sauls wrote:

 BCS wrote:

 Hello Jesse,


 On Wed, 18 Nov 2009 18:27:47 -0800, Andrei Alexandrescu wrote:


 Thanks! Question - is there a way to fetch the current Throwable from
 within a finally clause?

 Andrei


 I'm pretty sure you can't since finally isn't passed an exception. I
 also don't see anything in my quick search.


 That stands to reason because in some cases (when things go correctly) 
 there isn't one.


 
 One hopes.  Just the same: (hypothetical syntax incoming)
 
 try {
     // ...
 }
 catch ( ExceptionA exa ) {
     // ...
 }
 catch ( ExceptionB exb ) {
     // ...
 }
 finally ( x ) {
     // ...
     if ( x ) throw new ExceptionC( x );
 }
 
 And obviously if finally has no () it doesn't bother with the feature.
 
 -- Chris Nicholson-Sauls


I'm not that fancy. An API call getCurrentError returning an Error 
object or null is all that's needed. And more general too.

Andrei
Nov 20 2009
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Andrei Alexandrescu wrote:

 Chris Nicholson-Sauls wrote:

 BCS wrote:

 Hello Jesse,


 On Wed, 18 Nov 2009 18:27:47 -0800, Andrei Alexandrescu wrote:


 Thanks! Question - is there a way to fetch the current Throwable from
 within a finally clause?

 Andrei


 I'm pretty sure you can't since finally isn't passed an exception. I
 also don't see anything in my quick search.


 That stands to reason because in some cases (when things go 
 correctly) there isn't one.


 One hopes.  Just the same: (hypothetical syntax incoming)

 try {
     // ...
 }
 catch ( ExceptionA exa ) {
     // ...
 }
 catch ( ExceptionB exb ) {
     // ...
 }
 finally ( x ) {
     // ...
     if ( x ) throw new ExceptionC( x );
 }

 And obviously if finally has no () it doesn't bother with the feature.

 -- Chris Nicholson-Sauls


 
 I'm not that fancy. An API call getCurrentError returning an Error 
 object or null is all that's needed. And more general too.
 
 Andrei


At which point one could argue that the constructor of Throwable or Exception
could/should 
call that same API function itself.  I'm not strictly opposed to it, mind you,
it just 
bodes ill not to thoroughly examine such auto-magic.

-- Chris Nicholson-Sauls
Nov 21 2009
prev sibling parent BCS <none anon.com> writes:
Hello Chris Nicholson-Sauls,


 BCS wrote:
 

 That stands to reason because in some cases (when things go
 correctly) there isn't one.
 


 One hopes.  Just the same: (hypothetical syntax incoming)
 
 try {
 // ...
 }
 catch ( ExceptionA exa ) {
 // ...
 }
 catch ( ExceptionB exb ) {
 // ...
 }
 finally ( x ) {
 // ...
 if ( x ) throw new ExceptionC( x );
 }
 And obviously if finally has no () it doesn't bother with the feature.
 


IIRC the .NET CLI has some of what you want:

http://stackoverflow.com/questions/533968/c-finally-block-that-only-runs-on-exceptions
Nov 21 2009