UncheckedIOException and suppressed exception

[Sam Pullara]

Wouldn't all these exceptions extend from RuntimeException? Seems like
we already have both the generic version and the specific for the
callers.

Sam

All my photos are panoramas.

On Feb 4, 2013, at 7:56 PM, David Holmes <david.holmes at oracle.com> wrote:

> On 5/02/2013 1:39 PM, Zhong Yu wrote:
>> 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.
>
> Then the catch is showing their ignorance of suppressed exceptions. BUt
> this is not specific to this situation. Anytime you catch an exception
> with a cause and a suppression list you have to decide what it is you
> want to do with it.
>
>> 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".
>
> Again read the Throwable javadoc that Joe pointed out top you. This
> "conversion" situation is one of the primary uses for setting a cause:
>
> "A second reason that a throwable may have a cause is that the method
> that throws it must conform to a general-purpose interface that does not
> permit the method to throw the cause directly. For example, suppose a
> persistent collection conforms to the Collection interface, and that its
> persistence is implemented atop java.io. Suppose the internals of the
> add method can throw an IOException. The implementation can communicate
> the details of the IOException to its caller while conforming to the
> Collection interface by wrapping the IOException in an appropriate
> unchecked exception. (The specification for the persistent collection
> should indicate that it is capable of throwing such exceptions.) "
>
> David
> -----
>
>>>> 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
>