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

List:       openjdk-security-dev
Subject:    Answer requested!!! was: Re: 7081804: Remove	cause	field	from	javax.xml.crypto.NoSuchMechnismExcepti
From:       sebastian.sickelmann () gmx ! de (Sebastian Sickelmann)
Date:       2011-11-23 4:45:59
Message-ID: 4ECC7A87.1030604 () gmx ! de
[Download RAW message or body]

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).
>> 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_6/index.html



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