Fwd: Exception transparency

[Neal Gafter]

---------- Forwarded message ----------
From: Neal Gafter <neal at gafter.com>
Date: Mon, Oct 1, 2012 at 12:22 PM
Subject: Re: Exception transparency
To: lambda-spec-observers at openjdk.java.net
Cc: Brian Goetz <brian.goetz at oracle.com>


On Thu, Sep 20, 2012 at 3:03 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> It's possible, but its pretty ugly, really easy to get wrong, and (like
> everything else with generics) if the library writer gets it wrong, the
> user is hosed.  The generics foo overwhelms the simple body of the and()
> method.
>
> We've done a lot more investigation, but here is just a quick summary of
> disadvantages of BGGA-style exception transparency:
>
>  - Makes the declarations of functional interfaces and lambda-consuming
> methods more complicated
>

Actually, it has no effect on function interface and lambda-consuming
methods whatsoever.  If such methods require exception transparency, then
they pay the cost.  If not, then they do not.  By excluding support of
exception transparency from the language, you are simply making it
impossible to write methods that require exception transparency.  Keeping
this support out of the language is a judgment that such requirements are
adequately met by existing techniques (e.g. wrapping all exceptions in
something like like InvocationTargetException or making the API throw any
Exception like PrivilegedExceptionAction.run).


>  - Doubly so for combinator methods (e.g., Predicates.and)
>

Whether these methods require exception transparency and whether there are
requirements for exception transparency from ANY clients are two separate
judgments.

 - Requires extra args at the use site on the non-throwing case (e.g.,
> Predicate<String, Void>), which is ugly and “leaky” (though this could
> probably be patched up in common cases, at the cost of extra complexity)
>

You could easily decide that such type arguments may be elided rather than
require 'Void'.


>  - Challenges for retrofitting existing functional interfaces (e.g.,
> Runnable, Comparator) because most existing SAM types are not generic over
> exceptions
>

Why would you retrofit APIs that don't need the feature?  Or are you saying
they do need the feature but it is too late?


>  - Takes liberties with meaning of generic type params – sometimes they
> refer to types, sometimes to sets of types
>

These are always types in BGGA - with multiple thrown types the type
argument is a disjuctive type.

 - Inference undecidability – if you have a generic method that accepts a
> SAM type throwing both X1, X2, cannot partition the set of exceptions
> thrown by the lambda body
>

I think you may be misusing "decidability".  Isn't an arbitrary decision
here - for example based on the lexical ordering of the throws clause -
sufficient?  As a practical matter, it is hard to imagine a need for a SAM
type where the method is declared to throw multiple unconstrained type
parameters.

 - Unsoundness of “catch X” – X will be erased, and you would be catching
> Exception instead
>

This is already disallowed by the language.  It has nothing to do with
transparency.


>  - Would likely interact with future attempts to extend generics, such as
> varargs generics, which would be desirable for things like tuples
>

In BGGA, the throws type parameter is a single type (argument or
parameter), so it has no interaction with varargs generics.  Only the
ability to elide throws type parameters (as mentioned above) would cause an
interaction.  If the tuple type parameters are not "throws" type parameters
(as I would expect), then there is no conflict.

 - Not very transparent at all -- pretty intrusive, in fact.
>

It seems it has no impact on clients (APIs and client of those APIs) that
do not require this functionality.  At worst, APIs that support
transparency (such as, perhaps, SE SAM types) would impose some burden on
clients that explicitly implement APIs that operate over those SAM types,
but little or no burden on clients of those APIs.  But the APIs that
operate over those SAM types are largely Java SE libraries.  That is the
whole point of having core libraries - to shift the burden from end
programmers to the platform implementation.

Perhaps your conclusion is really that the functionality itself is unwanted
for the SE SAM types, and therefore there is no urgency for the language.