7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException (original) (raw)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Thu Oct 27 14:50:28 UTC 2011

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). 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/7011804_4/index.html [1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.htm <http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html>

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

-- Sebastian

Am 02.10.2011 21:49, schrieb Sebastian Sickelmann:

Am 01.10.2011 18:19, schrieb Sean Mullan:

On 9/30/11 2:15 PM, Sebastian Sickelmann wrote:

I think I know the reason. If you allow initCause to be called when a cause is not initially provided, then getCause will still return null, which seems wrong.

getCause() of Throwable and all classes that doesn't had a chaining before Throwable introduces it, doing this excact this way. Whats wrong on this? return (cause==this ? null : cause); // Where the initial value(uninitialied) of cause is this. Does this make sense? I actually not sure i understand you right. The following code: KeySelectorException kse = new KeySelectorException("foo"); kse.initCause(new Exception("bar")); System.out.println(kse.getCause()); prints null as the cause, even though initCause was subsequently called. Do you see my concern? This is one of the places in code which must be changes to match the initCause behavoir of Throwable. I have done it here: http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/70118045/index.html But is this the best way? Or should we just follow the other Exceptions and start an seperate discussion on this with core-libs-dev? http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/70118044/index.html Thanks! --Sean

-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20111027/7e09fc22/attachment.htm>

More information about the security-dev mailing list