3. Re: Checked exceptions within Block<T> (Brian Goetz)

waldo auf der springe wasprin at gmail.com
Tue Jan 15 14:59:15 PST 2013


>Or you could write your own trivial combinator:
>static<T> Block<T> exceptionWrappingBlock(Block<T> b) {
>     return e -> {
>         try { b.accept(e); }
>         catch (Exception e) { throw new RTE(e); }
>     };
>}
>
>You can write it once, in less that the time it took to write your
>original e-mail.  And similarly once for each kind of SAM you use.
>
>I'd rather we look at this as "glass 99% full" rather than the
>alternative.  Not all problems require new language features as
>solutions.  (Not to mention that new language features always causes new
>problems.)
The compiler will not allow this type of wrapping! I can not pass my lambda
expression to the exceptionWrappingBlock because of the fact that my lambda
throws a checked exception for which Block<T> can not be a target type. And
I think this is an important aspect in the discussion. Checked exceptions
are an intrinsic part of the java language, it comes with the character of
java being a language that gives a lot of compiler time consistency
checking. But checked exception's don't mix (well) with the general purpose
SAM interfaces that we now get as hooks to the java libraries. If we want
to hold on to checked exceptions when using SAMs for typing our lambdas,
then it should be taken all the way: the lambda will most of the time be
inlined, and then the compiler can check whether the checked exception
thrown in the lambda is caught in the invoking scope, or declared as throws.
This will work for most cases but I am sure a lot of elegant solutions will
break or get loitered when using non inlined lambdas. I respect that java
should have lambdas for which the compiler will check your exceptions, but
I feel that developers should also have the capability of using lambdas
that are not subject to compiler exception checking. If we mark those with
=> instead of -> then they are clearly marked and both camps win. I feel
this spec change would be well received in the java community.

Regards, Waldo auf der Springe


More information about the lambda-dev mailing list