Exception transparency III - The Advent of the No-Throw Area

[Alessio Stalla]

On Tue, Jun 15, 2010 at 11:23 AM, Gernot Neppert
<mcnepp02 at googlemail.com> wrote:
> So far, there have been 2 propsals to achieve exception transparency
> with closures:
>
> 1. the closure declares the the exception types it intends to throw,
> just like regular Java methods do.
> The throws declaration becomes part of the closure type, important for
> assignment conversions.
>
> 2. the closure declares that it can throw any kind of exception ("lone
> throws"). This declaration must be propagated to the calling code,
> effectively adding "sneaky throw" to the legitimate toolset of Java
> programming techniques.
>
> Just for the sake of completeness, I thought it might be worth
> mentioning the obvious third option:
>
> 3. "A closure must not throw Checked Exceptions".

Not that I think that 3. is a bad idea, but it does not achieve
exception transparency... except in the trivial sense that an empty
throws clause is implicitly transparent :)

Really, what Oracle wants - from my understanding of the discussion so
far - is to embed thrown exception information in closure types and
abstract over it. Any other option is not being considered. My
personal opinion is that this will unnecessarily complicate the
language and it will be seldom used outside of the standard API. But
of course my personal opinion doesn't count that much :)

Cheers,
Alessio

> This may look like a harsh restriction on first glance, but is it really?
> It may actually cover 80% of the usecases with 20% of the complexity
> of proposal 1.
>
> Here are some common scenarios for closures that will not make use of
> checked exceptions anyway:
>
> - Collections-related filtering or mapping functions
>
> - codeblocks passed to frameworks for asynchronous excecution (as long
> as they're converted to Runnable by automatic closure conversion)
>
> - codeblocks passed to GUI frameworks, since the corresponding SAMs
> (e.g. ActionListener) do not throw Checked Exceptions currently.
>
> Obvious advantages of this approach would be:
>
> - no involvement of the "throws" clause in the rules for assignement
> of closure types.
>
> - more readable declarations of methods that make use of closures.
>
>