Consistent Behavior of exception-chaining (original) (raw)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Thu Dec 15 16:46:55 UTC 2011

Hello,

while refactoring some exceptions (support for the 4 common ctors) i come along some inconsistency in handling cause-chaining via initCause method. I hope we can unify to a compatible solution that there is only one initCause-behavior for every Exception in JDK.

Here are the types i discovered:

Type 1: Disallow calls to initCause after creation. Type 2: Disallow calls to initCause after creation using a ctor which has a cause parameter. through Type 2 is the type used by Exceptions that had no cause-chaining (before it was introduced through Throwable). ex. java.lang.RuntimeException Type 1 is the type used by Exceptions that had a cause-chaining (before it was introduced through Throwable). ex. java.lang.ClassNotFoundException

Because there a two ways of looking at this feature i tried to realize which behavior i would expect. Lets call it Type 3.

Type 3: Disallow calls to initCause after creation if there is a ctor present which i had the change to specify a given cause. Which effectively is Type 1 if we introduce the 4 common-ctors to every Exception.

Type 3 has some problems. 1st: There maybe some cases in JDK codebase where the cause-plumbing is delayed so that it is a problem that initCause cannot be called later. I think this cases can be refactored to work with Type 3(1). 2nd: There are code-bases outside the jdk that uses the initCause-method. These would be binary compatible with Type 3(1) but are behavior-incompatible with it.

I think the second reason weight more than the first. And i think this is the deatchblow for Type 3.

So i think it concludes to the question: "Should we migrate the Type 1 Exceptions to Type 2?"

I think Type 1 Exceptions are only used by Exceptions that has a cause-chaining (before it was introduced through Throwable). There are some exception in javax/xml/crypto that had exception-chaining before it was introduced through Throwable. I had some discussion[1] with Sean Mullan about introducing exception-chaining to javax/xml/crypto in the way Throwable introduced it. We get to an solution[2] that implements Type 2.

Are there good reasons to not change Type 1 Exceptions to Type 2?

Kind regards Sebastian

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007399.html [2] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_8/index.html

More information about the core-libs-dev mailing list