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

[Gernot Neppert]

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

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.