Proposal: Improved Exception Handling for Java (original) (raw)

Neal Gafter neal at gafter.com
Tue Mar 3 07:04:04 PST 2009

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