Proposal: Improved Exception Handling for Java

Joseph D. Darcy Joe.Darcy at Sun.COM
Wed Mar 4 15:11:55 PST 2009


Hello.

I'd prefer to see this listed as an alternative in the next iteration of 
the Improved Exception Handling draft to the problem of source 
incompatibility, an incompatibility we might be able to live with anyway.

I think a general foreign interoperability proposal while interesting, 
would be outside the focus of Project Coin.

-Joe

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




More information about the coin-dev mailing list