Answer requested!!! was: Re: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException
Sebastian Sickelmann
sebastian.sickelmann at gmx.de
Wed Nov 23 04:45:59 UTC 2011
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
More information about the security-dev
mailing list