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

Weijun Wang weijun.wang at oracle.com
Fri Dec 16 02:29:20 UTC 2011

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

Maybe serialization compatibility?

-Max

On 12/16/2011 12:46 AM, Sebastian Sickelmann wrote:

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/70118048/index.html

More information about the core-libs-dev mailing list