suppressedException semantics (original) (raw)

David Holmes David.Holmes at oracle.com
Wed Aug 25 15:28:22 PDT 2010

Reinier Zwitserloot said the following on 08/25/10 23:49:

On Wed, Aug 25, 2010 at 1:03 PM, David Holmes <David.Holmes at oracle.com_ _<mailto:David.Holmes at oracle.com>> wrote:

I don't see how the lack of tools is relevant to the question. You will want to follow the chain of exceptions no matter which one is chosen to be thrown. Why? Once I see a trace that explains the problem, I stop reading. The faster that happens, the happier I'd be.

Well if you're sure none of the other exceptions indicate real problems that need to be addressed, that is your call.

It is far from obvious to me that if there are "many tens of stack traces" then there even exists a "primary" one, let alone that that will be the exception being thrown under the current proposal.

One of them is going to be printed first. Unless you're suggesting we officially state that the order in which exceptions print will henceforth be undetermined, but I don't think that's a good idea.

Of course one of them will be printed first - and then we have issues of printing breadth first or depth first with the cause and suppressedExceptions.

My point is that it doesn't matter which one is printed first, so why not stick with an order that is consistent with the existing language semantics?

I don't see cost:benefit in the right proportions here in the general case. If we were limited to one resource per try-with those proportions improve significantly.

As I've said YMMV.

David

More information about the coin-dev mailing list