7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException
sebastian.sickelmann at gmx.de
Thu Oct 27 07:50:28 PDT 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 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 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.
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
>>>> Throwable introduces it, doing this excact this way. Whats wrong on
>>>> 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"));
>> 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:
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the security-dev