Message11283

@Stefan I'm at work at them moment so will try to post the classes and methods tonight, but just a few comments

1. The new example is exactly right, I haven't tried it, but to get a StackOverflowError to occur in the finally is very easy in this situation, as you say the stack is very nearly exhausted already, so any method call could cause it.

2. Once you throw in the finally I believe the new exception replaces the existing one, I will check this tonight but remember investigating it once before for another reason. In this case it will be a new StackOverflowError but the stack it contains will be smaller as you have already dropped a stack frame maybe more, I think this is the source of a lot of the confusion around this. In this situation the stack trace you see in any exception will be only a partial stack. If anyone knows I'm wrong please correct this, because I think this is a key point which we should be clear on.

3. What makes you think the StackOverflowError thrown in the finally doesn't propagate up the stack? Looking at you example, I would suggest that only the last catch needs to succeed in catching the StackOverflowError and you will see nothing, as every time a new StackOverflowError is thrown the old one is lost?

Disclaimer: I might be wrong on any of this (If I am please correct me), I didn't even run the example its just from looking at the code but though it might be useful for discussion.

Also I don't know if it relevant here but throwing an exception over another, suppresses the first they is now a Java way to recover these see Throwable.getSuppressed but i'm not sure if it will apply in this case.