Exception transparency

[Peter Levart]

On 06/11/10, Neal Gafter wrote:
> On Thu, Jun 10, 2010 at 4:36 PM, maurizio cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
> 
> >  But due to a previously unreported compiler bug (I'm using javac version
> >> 1.6.0_07), it won't compile anyway.  I'll be surprised if anyone can find
> >> production code that compiles today and would break under a hypothetical
> >> change to lub() for all type parameters that extend Throwable or a
> >> subtype.
> >>
> >>
> > The program I posted earlier in this thread compiles correctly under jdk 6
> > and would fail with the proposed extension of dropping lub() in favor of
> > disjunctive types for type-variables extending Throwable. It's clearly not
> > production code, but it's something.
> 
> 
> Agreed: you can't make much of a change without breaking some hypothetical
> program.  But breakage that is only hypothetical isn't much to worry about.
> 
> I believe "extends Exception" and its ilk is more than enough of a hint to
> the programmer what is intended without the addition of a further "throws"
> keyword in the type parameter.
> 

I aggree with Neal that these marginal use cases are purely hypothetical. The fact that even Throwable bound type parameters are currently infered as lub() is rendering such hypothetical usages useless so we can reasonably expect they are nonexistent in real code. By introducing different rules of inference for Throwable bound type parameters and not restricting their usages a whole new world of possibilities for checked exception handling opens.

Regards, Peter