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

Joseph D. Darcy Joe.Darcy at Sun.COM
Wed Mar 4 15:08:03 PST 2009

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

More information about the coin-dev mailing list