Proposal: Improved Exception Handling for Java

[Joseph D. Darcy]

Neal Gafter wrote:
> 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.
>   

Okay.

>>> 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?
>   

Yes; effectively sets of exception types are being computed and operated 
on; it would help clarify some of hter interactions for me to see some 
worked examples.

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

Without the final rethrow, do actual disjunctive types need to be added 
to support multi-catch?

Thanks,

-Joe