UncheckedIOException and suppressed exception

[Zhong Yu]

On Mon, Feb 4, 2013 at 11:03 PM, Ricky Clarkson
<ricky.clarkson at gmail.com> wrote:
> If you're expecting catch (UncheckedIOException e1) { throw e.getCause(); }
> as a common use case, perhaps using the return value might be a better
> approach without having to 'dip' down into untypedville:
>
> List<IOResult<String>> resultList = asList("foo.txt",
> "bar.txt").map(trapIOException(IOUtils::readWholeFile));
> for (IOResult<String> possibleResult: resultList) {
>   String result = possibleResult.getValue(); // would rethrow the original
> IOException or return the value depending on what's stored in the IOResult.
>   more code here using result.
> }

Good idea. The behavior is a little different though - in your
version, all files are processed, even if an individual file fails -
while we were discussing an exception that propagate through and
destroy the loop. Another problem is how to propagate error easily.
What I can think of is

    IOResult<String> foo()
        IOResult<String> x = ...;
        if(x.isError()) return x; // propagate
        ...

which is a little cumbersome.

The bigger problem is it's not a recognized practice in current java
world. API authors would hesitate to return errors instead of throw
errors, so this practice is difficult to spread, it likely will remain
private in isolated programs.

> If Java 9 later provided exception transparency, you could then refactor
> this code fairly straightforwardly with IDE support or at least with help
> from the compiler, whereas if you have to go via an unchecked exception it's
> likely to be harder to take advantage of any future improvements.  This
> should also work with parallelism, as there's nothing making .map terminate
> as soon as reading one file hits an IOException.
>
> Checked exceptions are contentious and I'm not sure I'd include them if I
> was designing a language,

True, but the new language would have other devices that make error
handling easier.

> but they're in Java, they get some valid use that
> benefits from type checking and I wouldn't want to see them become a
> second-class citizen by being excluded from most lambda-using code in favour
> of untyped exceptions.

True, the wrapper is less typed; hopefully it's used in contexts where
it's clear what are the possible types of the original exception.

In any case, UncheckedIOException is an odd ball that's bound to raise
questions - what about UncheckedFileNotFoundException? what about
UncheckedAnyException? What's so special about IOException that only
it gets an unchecked cousin?


>
> On Tue, Feb 5, 2013 at 1:17 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> On Mon, Feb 4, 2013 at 9:47 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.
>>
>> It is far more likely that UncheckIOException is treated as a shell,
>> and the shell is discarded (along with information attached to it),
>> leaving only the contained IOException. That is less likely for
>> "normal" exceptions that represents errors by themselves.
>>
>> This is probably going to be a common usage
>>
>>     catch(UncheckedIOException e1)
>>         throw e.getCause();
>>
>> however it'll lose suppressed exception on e1.
>>
>> >> 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:
>>
>> I'm certainly aware of this practice, unfortunately it is not a good
>> practice, since there's no reliable way to uncover the original
>> exception.
>>
>> > "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
>> >>>>
>> >>>
>> >>
>> >
>>
>