Consistent Behavior of exception-chaining

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



More information about the core-libs-dev mailing list