Proposal: Improved Exception Handling for Java

[Reinier Zwitserloot]

Maybe I'm making this too simple, but what if javac will treat all  
catch blocks of a type that isn't thrown by the try block as warnings  
instead of errors? That fixes Neal's Improved Exception Handling issue  
of not being 100% source compatible with java 6, no?

I assume source compatibility where code that is clearly broken  
results in a warning in java 7 (but is still compiled with exactly the  
same semantics) whereas it was silently compiled by java 6 is only  
good news.

Also, because in just about every other language on the JVM, checked  
exceptions can be thrown without being declared, I think this is a  
good idea in general, considering that java wants to be more  
interoperable with non-java JVM languages. To work around this issue  
now, you have to either wrap the call in a wrapper method that adds  
the exception to the throws list, or you have to create a dummy method  
that declares the throwable in the throws list but doesn't throw it,  
just so javac will stop refusing to compile your code. That's clearly  
a hack solution, and the elimination of it should be a good thing,  
even if you need to use a @SuppressWarnings instead, no?

Should I write up a proposal for this? Should Neal add it to his  
proposal? Or is it just a horribly stupid idea? :)

  --Reinier Zwitserloot



On Mar 3, 2009, at 08:33, 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.
>
>>> 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.
>