UncheckedIOException and suppressed exception

[Zhong Yu]

On Mon, Feb 4, 2013 at 7:56 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 5/02/2013 10:16 AM, Zhong Yu wrote:
>>
>> Suppose we have an UncheckedIOException e1, which wraps an IOException
>> e2. Then another exception e3 occurs that we want suppress. Should we
>> do e1.addSuppressed(e3), or e2.addSuppressed(e3)? That's pretty
>> confusing.
>
>
> I don't see any confusion except for your numbering. You have one exception
> that is inflight, e1, and then e3 occurs. If you want to continue throwing
> e1 then e1 is suppressing e3.

The catcher of an UncheckedIOException e1 would see it simply as a
container, so it'll extract the contained IOException e2, and deal
with e2 afterwards, for example, rethrow e2. If e3 was added as e1's
suppressed exception, e3 is then lost.

This "containing" relation is different from the usual "causal"
relation between an exception and its cause. Let's be honest, the only
purpose of an UncheckedIOException is to smuggle an IOException as
unchecked; UncheckedIOException itself has no "business meaning".

>> If UncheckedIOException is not a *real* exception, maybe we should
>> make it a "control" exception. It should have no stacktrace; it should
>> have no cause (the wrapped exception is not a cause); it should not
>> contain suppressed exceptions.
>
>
> Any wrapping exception should have the original exception as its cause. Why
> should this wrapper be any different? Throwable even defines it so:
>
> " Throwing a "wrapped exception" (i.e., an exception containing a cause)
> ..."
>
> Suppression is about control over which exception is propagating - so again
> why should this be a special case?
>
>
>> Maybe it can override addSuppressed() to forward suppressed exceptions
>> to the wrapped exception. (Though addSuppressed() is `final`, there's
>> no problem to leave a backdoor for another JDK class)
>
>
> I think your exception processing model is slightly confused here.
>
> David
> -----
>
>> Zhong Yu
>>
>