Answer requested!!! was: Re: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException

[Sean Mullan]

On 11/22/2011 11:45 PM, Sebastian Sickelmann wrote:
> 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).

webrev[0] looks like it is using Solution 1. Looking at the diffs for 
KeySelectorException, the ctors that don't supply cause parameters are 
still forbidden from subsequently calling initCause.

 >>> The problem with Solution 3 is that bahavoir compatibility is not 
given
 >>> and some code may break.

Can you please explain what you think the compatibility issues are in 
more detail?

I would also like to see the diffs for solution 2 before I give you my 
opinion.

--Sean



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