[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-security-dev
Subject:    7081804: Remove cause field	from	javax.xml.crypto.NoSuchMechnismException
From:       sebastian.sickelmann () gmx ! de (Sebastian Sickelmann)
Date:       2011-10-27 14:50:28
Message-ID: 4EA96FB4.7000502 () gmx ! de
[Download RAW message or body]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20111027/7e09fc22/attachment.html 

[prev in list] [next in list] [prev in thread] [next in thread]