Proposal: Improved Exception Handling for Java

[Neal Gafter]

On Mon, Mar 2, 2009 at 10:29 PM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
>> MAJOR DISADVANTAGE:
>>
>> One-time implementation cost for adding the features to the compiler.
>> Longer language specification in describing the behavior.
>>
>
> What sort of poor programming practices could this feature encourage or
> enable?

I don't see any, but perhaps I'm shortsighted.

>> The type system is affected as follows: For the purpose of type
>> checking, a catch parameter declared with a disjunction has type
>> lub(t1, t2, ...) [JLS3 15.12.2.5].
>
> In terms of finding the members of the type, it is good existing concepts in
> the JLS can be used.
>
> What happens if someone writes
>
>   catch(final IOException | SomeSubclassOfIOException e) {...}
>
> In other words, is it legal to have subclasses of a caught exception listed
> too?

I don't really care one way or the other.  As written, yes, it is
allowed and means the same thing as the supertype alone.

>> To avoid the need to add support for general disjunctive types, but
>> leaving open the possibility of a future extension along these lines,
>> a catch parameter whose type has more than one disjunct is required to
>> be declared final.
>>
>
> I think that is a fine compromise that keep the current feature smaller
> while allowing room for a broader feature later.
>
> Some worked examples of the sets of thrown exceptions types under various
> tricky code samples would help clarify the data flow algorithm for me.

Sure, I can do that.  Do you think that should go in the specification?

>> A catch clause is currently compiled (before this change) to an entry
>> in an exception table that specifies the type of the exception and the
>> address of the code for the catch body. To generate code for this new
>> construct, the compiler would generate an entry in the exception table
>> for each type in the exception parameter's list of types.
>>
>
> Interesting; so there would be no code duplication even in the class files.

Correct.  That's what the current prototype (in the BGGA compiler)
does for this construct.

> How could the increased exception precision be maintained will still allow
> programs such as the one above to compile?

I don't think it can without making rather complex rules, but I'll
think about it more.

However, one could take only the multicatch part of this proposal and
not the final/rethrow part, and then I believe one could specify it
without there being a breaking change.