Answer requested!!! was: Re: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException (original) (raw)

Sean Mullan sean.mullan at oracle.com
Thu Dec 1 15:12:22 UTC 2011

On 11/22/2011 11:45 PM, Sebastian Sickelmann wrote:

It's been a long time ago. Had someone had the time to think about this:

Am 29.10.2011 13:17, schrieb Sebastian Sickelmann: Sorry i linked the wrong webrev for Solution 3.

Am 27.10.2011 16:50, schrieb Sebastian Sickelmann: Some time ago (see below) i ask what would be the right solution to refactor exception initialization to?

Solution 1: Disallow calls to initCause after creation, if there was an exception-cause-functionality in this class before it was introduced to Throwable. Solution 2: Disallow calls to initCause after creation with in ctor which has a cause parameter. Solution 3: Disallow calls to initCause after creation, if and only if there are ctors that allows us to specify the cause at creation time.

If i investigated it right:: * Solution 1 is used by in the Exceptions in core-libs. * Exceptions that had no cause-chain prior to Throwable's-cause-chain uses Solution 2. * Personally i found Solution 3 is the most intuitive for the users javax/xml/security- Exceptions had cause-chaining prio to Throwable introduces them. jx/x/s-Exceptions are actually not refactored to solution 2 like the other exceptions in core-libs that had cause-chaining prior to Throwable. Before my change-request for jx/x/s-Exceptions i changed some in core-libs (InternalError and VirtualMachineError) to provide exception-chaining. These use Solution 2 like all other exceptions that provided exception-chaining after it where introduced by Throwable. My personal view of this is that i think it may be valueable to change all to Solution 3 or at least merge all Solutions to one Solution(maybe Solution 2) and get rid of Solution 1. I created a webrev[0] for jx/x/s-Exceptions that implements Solution 2 (this can be used for all those Exceptions that used Solution 1 too).

webrev[0] looks like it is using Solution 1. Looking at the diffs for KeySelectorException, the ctors that don't supply cause parameters are still forbidden from subsequently calling initCause.

The problem with Solution 3 is that bahavoir compatibility is not given and some code may break.

Can you please explain what you think the compatibility issues are in more detail?

I would also like to see the diffs for solution 2 before I give you my opinion.

--Sean

And I created a webrev[1] for jx/x/s-Exceptions that implement Solution 3 for comparision.

[0] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/70118044/index.html

[1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/70118046/index.html

More information about the core-libs-dev mailing list