experience trying out lambda-8-b74
Zhong Yu
zhong.j.yu at gmail.com
Mon Feb 4 19:48:55 PST 2013
On Mon, Feb 4, 2013 at 8:45 PM, Ricky Clarkson <ricky.clarkson at gmail.com> wrote:
> "And there's nothing harmful
> to make a more general UncheckedAnyException, instead of just
> UncheckedIOException."
>
> What's wrong with RuntimeException for that?
We cannot unambiguously determine whether a RuntimeException e1 is a
simple wrapper of an checked exception e2 for the purpose of smuggling
e2 across a method that doesn't throw checked exception, or an
ordinary exception that represents an erroneous condition by itself.
We had a similar discussion on Doug Lea's CompletableFuture.
Originally it used RuntimeException to smuggle checked exceptions. It
was then changed to use a specific "CompletionException" for the
purpose. My fear is that each library will invent its own wrapper
exception for the purpose. Why not have an official wrapper?
> On Mon, Feb 4, 2013 at 8:32 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> On Mon, Feb 4, 2013 at 5:11 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>> > I knew it wouldn't be long before this turned into yet another
>> > barely-laundered proposal to try yet again to get us to deprecate
>> > checked
>> > exceptions. I get it, you find checked exceptions frustrating.
>> > Sometimes I
>> > do too. But we still believe a world without them would be worse, and
>> > we're
>> > not interested in pushing people towards that.
>>
>> I neither hate or love checked exceptions; they are here, they are
>> widely used by Java applications, so we must deal with it.
>>
>> > There are places in the Java libraries -- mostly from the very early
>> > days --
>> > where the use of checked exceptions turned out to be a mistake. (An
>> > obvious
>> > example is close() throwing IOException -- what could a user possibly do
>> > to
>> > recover from that?) The workarounds we're doing here are to mitigate
>> > the
>>
>> (digression - failure of close() is real and is important; at least
>> app can tell the user that the file can't be saved, instead of
>> assuming otherwise)
>>
>> > worst mistakes of the past, not to rewrite history. And we're satisfied
>> > that this small workaround handles 90% of the 2% of cases where
>> > exceptions
>> > turn out to intrude in lambda libraries. So we've made the decision to
>> > stop
>> > there for now, and not because it didn't occur to us to go farther.
>>
>> I don't quite get it - are you saying that IOException is the 90% of
>> the checked exceptions, so UncheckedIOException is good enough,
>> instead of a more generic wrapper for arbitrary Exception.
>>
>> I don't think IOException is that special. And there's nothing harmful
>> to make a more general UncheckedAnyException, instead of just
>> UncheckedIOException.
>>
>> >
>> >
>> > On 2/4/2013 6:03 PM, Zhong Yu wrote:
>> >>
>> >> On Mon, Feb 4, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com>
>> >> wrote:
>> >>>
>> >>> If we don't extend any exception handling or need type information, we
>> >>> don't really need a wrapper as Throwable already has hasCause()
>> >>> method.
>> >>
>> >>
>> >> UncheckedIOException is a wrapper for IOException. I'm arguing that
>> >> JDK should instead have a generic wrapper for Exception, so that all
>> >> libraries have a uniformed way of smuggling/unsmuggling checked
>> >> exceptions. Otherwise there are serious interoperability obstacles.
>> >>
>> >> It appears that the lambda team does not take checked exceptions
>> >> seriously. It might be the right attitude academically, but real world
>> >> Java applications are full of checked exceptions. Without a guideline
>> >> from Java czars, lots of hacky ways will be invented when they try to
>> >> integrate with Stream.
>> >>
>> >> Zhong Yu
>> >>
>> >>> I recall there were discussion of transparent exception handling,
>> >>> which
>> >>> is still an open topic I believe.
>> >>>
>> >>> Cheers,
>> >>> Henry
>> >>>
>> >>> On Feb 2, 2013, at 9:06 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>> >>>
>> >>>> Also, what about other checked exceptions? If I make a stream based
>> >>>> on
>> >>>> JDBC ResultSet, how do I handle SQLExceptions? Should I create a
>> >>>> proprietary UncheckedSQLException? Should multiple libraries each
>> >>>> provide their own version of UncheckedXxxExceptions for every
>> >>>> XxxException? We'll be in this hell for some years to come before the
>> >>>> language gives a better device.
>> >>>>
>> >>>> Meanwhile, why not provide a generic wrapper exception whose explicit
>> >>>> and sole purpose is to wrap another checked exception? I know the
>> >>>> idea
>> >>>> is trivia, but why not?
>> >>>>
>> >>>> The Wrapper can provide convenience methods like
>> >>>>
>> >>>> class Wrapper extends RuntimeException
>> >>>>
>> >>>> // if cause is E1, throw cause; otherwise throw wrapper.
>> >>>> <E1> RuntimeException rethrow(Class<E1> type) throws E1,
>> >>>> Wrapper
>> >>>>
>> >>>> so we can
>> >>>>
>> >>>> catch(Wrapper w)
>> >>>> throw w.rethrow(IOException.class, SQLException.class);
>> >>>>
>> >>>> or to handle causes inline
>> >>>>
>> >>>> catch(Wrapper w)
>> >>>> w.on(IOException.class, e->{ handle e; })
>> >>>> .on(SQLException.class, e->{ handle e; });
>> >>>>
>> >>>> <Ei, Eo> Wrapper on(Class<Ei> type, ExceptionHandler<Ei,Eo>)
>> >>>> throws
>> >>>> Eo;
>> >>>>
>> >>>> interface ExceptionHandler<Ei,Eo>
>> >>>> void handle(Ei e) throws Eo;
>> >>>>
>> >>>> obviously not elegant, but at least give us something of the sort
>> >>>> that
>> >>>> can alleviate the pain in the short term.
>> >>>>
>> >>>> Zhong Yu
>> >>>>
>> >>>>
>> >>>> On Fri, Feb 1, 2013 at 11:38 PM, Peter Levart
>> >>>> <peter.levart at gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> On 02/02/2013 12:44 AM, Henry Jen wrote:
>> >>>>>>
>> >>>>>> On 01/28/2013 12:16 AM, Peter Levart wrote:
>> >>>>>>>
>> >>>>>>> On 01/28/2013 12:06 AM, Henry Jen wrote:
>> >>>>>>>>
>> >>>>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>> >>>>>>>>
>> >>>>>>> Hi Henry,
>> >>>>>>>
>> >>>>>>> I can imagine that many times a single block of code would be
>> >>>>>>> responsible for constructing a Path stream (possibly enclosed into
>> >>>>>>> a
>> >>>>>>> try-with-resources construct) and consuming it's results, so
>> >>>>>>> having
>> >>>>>>> to
>> >>>>>>> deal with the duality of IOException/UncheckedIOException is a
>> >>>>>>> complication for a user in my opinion. Wouldn't it be better also
>> >>>>>>> for
>> >>>>>>> the stream-factory methods to throw UncheckedIOException and for
>> >>>>>>> CloseableStream.close() to also throw UncheckedIOException (that
>> >>>>>>> means,
>> >>>>>>> only inheriting from AutoCloseable, not Closeable and
>> >>>>>>> co-variant-ly
>> >>>>>>> redefining the throws declaration):
>> >>>>>>>
>> >>>>>>> public interface CloseableStream<T> extends Stream<T>,
>> >>>>>>> AutoCloseable
>> >>>>>>> {
>> >>>>>>> @Override
>> >>>>>>> void close() throws UncheckedIOException;
>> >>>>>>> }
>> >>>>>>>
>> >>>>>> Hi Peter,
>> >>>>>
>> >>>>>
>> >>>>> Hi Henry,
>> >>>>>
>> >>>>>> Sorry for the late reply, I want to let the idea sink a little bit.
>> >>>>>>
>> >>>>>> After couple days, I am slightly prefer not to change it because,
>> >>>>>>
>> >>>>>> 1) The CloseableStream-factory method throws IOException reminds
>> >>>>>> use
>> >>>>>> of
>> >>>>>> try-with-resource better than an unchecked exception.
>> >>>>>
>> >>>>>
>> >>>>> The *Closeable*Stream method return type name also reminds of that
>> >>>>> ;-)
>> >>>>>
>> >>>>>> 2) As factory methods throwing IOException, developer is dealing
>> >>>>>> with
>> >>>>>> duality already.
>> >>>>>
>> >>>>>
>> >>>>> He is dealing with duality already *if* the factory methods are
>> >>>>> throwing
>> >>>>> IOException. If they are throwing UncheckedIOException, he is not
>> >>>>> dealing with duality.
>> >>>>>
>> >>>>>> 3) If the close method throws UncheckedIOException as the stream
>> >>>>>> handling, the suppressing of exceptions will be more confusing.
>> >>>>>> Should
>> >>>>>> developer look into cause IOException or the UncheckedIOException?
>> >>>>>
>> >>>>>
>> >>>>> Do you think a programmer might want to handle different subtypes of
>> >>>>> IOException differently? If that is the case, the javadoc should
>> >>>>> document all the possible situations. And what about different
>> >>>>> subtypes
>> >>>>> of IOException wrapped by UncheckedIOException while consuming the
>> >>>>> stream? If the programmer already bothers to unwrap the unchecked
>> >>>>> exception to do the cause analisys, then this same handler would be
>> >>>>> good
>> >>>>> also for dealing with exceptions thrown in factory methods and
>> >>>>> CloseableStream.close(). The streams API is a higher-lever wrapper
>> >>>>> over
>> >>>>> the java.nio.file.DirectoryStream API and it is already wrapping the
>> >>>>> lower-level IOException with UncheckedIOException when consuming the
>> >>>>> CloseableStream. I think it should do it consistently. By doing it
>> >>>>> consistently, it simplifies correct exception handling logic in
>> >>>>> *all*
>> >>>>> situations.
>> >>>>>
>> >>>>>> 4) When the implementation is a Closeable, the wrapping of
>> >>>>>> IOException
>> >>>>>> into an UncheckedIOException doesn't do any good except overhead in
>> >>>>>> case
>> >>>>>> developer want to deal with it. On the other hand, a IOException
>> >>>>>> handler
>> >>>>>> is probably in place as the factory methods throws IOException.
>> >>>>>
>> >>>>>
>> >>>>> It is probably in place *if* the factory methods are throwing
>> >>>>> IOException. If they are throwing UncheckedIOException, then such
>> >>>>> handler is not there. The question is whether the
>> >>>>> UncheckedIOException
>> >>>>> handler is in place too. If I look in one of your tests:
>> >>>>>
>> >>>>> 148 public void testWalk() {
>> >>>>> 149 try(CloseableStream<Path> s =
>> >>>>> Files.walk(testFolder)) {
>> >>>>> 150 Object[] actual =
>> >>>>> s.sorted(Comparators.naturalOrder()).toArray();
>> >>>>> 151 assertEquals(actual, all);
>> >>>>> 152 } catch (IOException ioe) {
>> >>>>> 153 fail("Unexpected IOException");
>> >>>>> 154 }
>> >>>>> 155 }
>> >>>>>
>> >>>>>
>> >>>>> You haven't bothered to handle the UncheckedIOException (because the
>> >>>>> test would fail anyway if it was thrown). But I'm afraid that
>> >>>>> average
>> >>>>> programmer will walk away from similar codes with false sense of
>> >>>>> confidence that he handled all exceptional situations when he put
>> >>>>> the
>> >>>>> checked exception handler in place. I think that being consistent
>> >>>>> and
>> >>>>> throwing UncheckedIOException everywhere would actually have greater
>> >>>>> probability for average programmer to not miss the handling of
>> >>>>> exceptional situations while consuming the stream - at least all
>> >>>>> exceptional situations would be handled or not handled equally.
>> >>>>>
>> >>>>> Regards, Peter
>> >>>>>
>> >>>>>> Does it make sense?
>> >>>>>>
>> >>>>>> I updated the webrev to have some test coverage for exception
>> >>>>>> handling,
>> >>>>>> it's painful as always, but the duality is not what bothers me.
>> >>>>>>
>> >>>>>> http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/
>> >>>>>>
>> >>>>>> Cheers,
>> >>>>>> Henry
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>
>> >>
>> >
>>
>
More information about the lambda-dev
mailing list