Proposal: ARM and SuppressedException

[Peter Jones]

On Sep 7, 2009, at 1:08 PM, Neal Gafter wrote:

> I have a problem with this from a software engineering point of  
> view.  While
> you've certainly found a place to put these exceptions without  
> adding any
> further fields, it's hard to see how making the suppressed exception
> masquerade as a cause of some other exception will assist in  
> locating or
> diagnosing the problem.

I agree that this would be undesirably confusing.  Also, it wouldn't  
work: a Throwable's cause can be initialized to null, at which point  
the chain can't be extended.

> On the other hand, this isn't much worse than the current proposal.   
> It's to
> see how the current proposal supports handling of suppressed  
> exceptions,
> unless code to check for them are sprinkled liberally throughout (the
> exception handlers of) a code base.

I assume that the expectation is that suppressed exceptions would be  
largely for consumption by humans (in log files, etc.), not programs.

I just reread through the proposal linked below, and while I concur  
with the motivation for adding a mechanism to retain what would  
otherwise be suppressed exceptions, like the debugging complications  
mentioned here:

>> Even the “correct” idioms for manual resource management are  
>> deficient: if an exception is thrown in the try block, and another  
>> when closing the resource in the finally block, the second  
>> exception supplants the first, making it difficult to determine the  
>> real cause of the trouble.  In other words, by responsibly closing  
>> your resource even during some catastrophic event, you can actually  
>> erase all record of the event, resulting in many wasted hours of  
>> debugging. While it is possible to write code to suppress the  
>> second exception in favor of the first, virtually no one does, as  
>> it is just too verbose. This is not a theoretical problem; it has  
>> greatly complicated the debugging of large systems.

it seems to me that this problem is more general than just the try/ 
finally cases that apply to ARM, so I wonder if the orthogonality of  
the mechanism to ARM can be further maximized.

For example, I could imagine liking an alternate universe where all  
finally blocks made use of Throwable.addSuppressedException, but in  
the opposite sense (so as to minimally differ from existing  
semantics)-- i.e., if a finally block completes with an exception  
after its try block (or the executed catch block) also completed with  
an exception, then the exception thrown by the try/catch gets recorded  
as a suppressed exception of the one ultimately thrown by the  
finally.  I think that this could aid in the above-mentioned debugging  
of much existing code.  But without having thought about it deeply, I  
suspect that making such a change now would be deemed too disruptive.

-- Peter


> 2009/9/7 Frédéric Martini <frederic.martini at gmail.com>
>
>> Hello (and sorry for my poor english),
>>
>>
>> I've juste reading the most recent version of the proposal :
>> http://docs.google.com/View?id=ddv8ts74_3fs7483dp
>> And I've a suggestion about the suppressed's exception.
>>
>>
>> Instead of adding addSuppressedException()/ 
>> getSuppressedExceptions() to
>> throwable, we can use the "initCause" to store the suppressed  
>> exception.
>> For example by adding a method like this on Throwable :
>>
>>
>>
>>   public void addInitCause(Throwable suppressedException) {
>>       Throwable t = this;
>>       while (t.getCause()!=null) {
>>           t = t.getCause();
>>       }
>>       t.initCause(suppressedException);
>>   }
>>
>>
>>
>> So we have not need to modify the printStackTrace()'s method, the
>> suppressed's exception will be added at the end of the initCause...
>>
>>
>> Fred,
>>
>>
>