experience trying out lambda-8-b74

[Henry Jen]

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.

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
>>> 
>> 
>>