Proposal: Improved Exception Handling for Java

[Neal Gafter]

I think relaxing the rules for interoperability is a great idea.  I
know a few places where Java's language rules interfere with
interoperability, but I wasn't aware of this one before.  I suggest
you write it as a separate proposal, please.

On Tue, Mar 3, 2009 at 2:06 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> 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.
>>
>
>
>