7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException

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 
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.


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/7011804_5/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/7011804_4/index.html 
>> Thanks!
>> --Sean

More information about the core-libs-dev mailing list