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

[Reinier Zwitserloot]

You're forgetting:

4. Introduce pure/impure closures and get exception transparency for free,
though that will turn your closure into an impure closure. Where pure
closures are required, you'd go with "no transparency" - the closure has to
handle (or explicitly declare as thrown onwards) any checked exceptions.
Fortunately a casual glance at APIs show that where pure closures are
required, exception transparency doesn't make nearly as much sense as those
API calls where impure closures are allowed.


Also, filtering, mapping, etc on collections-related classes can still
involve checked exceptions. Here's a trivial real world example of this:

public List<String> byteArraysToStrings(List<byte[]> data, String encoding)
throws UnsupportedEncodingException {
    return data.map(#(byte[] in)(new String(in, encoding)));
}

The above isn't going to work without some sort of exception transparency,
and that's a shame, because the above flow is correct; if the language
doesn't compile the above, that's entirely the fault of the language and not
from the developer.



--Reinier Zwitserloot



On Tue, Jun 15, 2010 at 10: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".
>
> 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.
>
>