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

[Sebastian Sickelmann]

Am 01.12.2011 16:12, schrieb 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 
>>>
>>>
>>
>
The 3 solutions I mentioned are solutions that can be commonly discussed 
for a solution choosing for all Exceptions in OpenJDK.

Webrev[0] shows solution 1 for jx/x/s-Exceptions. From the users 
perspective (outside view) solution 1 and 3 are completely similar.

Solution 2 are used widely in jdk codebase in Exceptions that had no 
chaining before it was introduced globally throught java/lang/Throwable.
An Example for Solution2 is java/lang/RuntimeException.
An webrev that show this jx/x/s-Exception is webrev[1]

Solution 3 is actually not used by any Exception in JDK (or I haven't 
found them)

The problem i see is that we now have 2 ways exception-chaining might work.

  * Solution 1 disallows chaining after creation.
  * Solution 2 disallows chaining only after creation with an ctors that 
supports it or after a call to initCause.

We should only support one solution.
If we introduce the commonly used exception-ctors for every class (which 
i actually try) we can switch over to an solutions that is consistent 
for the user. I think every Exception that gives the user the choice to 
use exception-chaining via a ctor-variant that supports chaining should 
disallow changes of the exception-chain via initCause even when the 
exception is created with an ctor that doesn't had chaining parameters.
This is what i call Solution 3.

Unfortunately Solution 3 introduces an behavior-incompatibility. In JDK 
every think is fine and we can make all the changes that are needed to 
do (replace all initCause calls with the right ctor-choice). But in the 
outside world there maybe users that rely on the feature of plumbing up 
the exception chain after creation. Those will get an Exception when 
they call initCause. Maybe we can warn them to not use initCause anymore 
through marking initCause deprecated. And switch over to solution 3 over 
several releases (maybe OpenJDK9 or 10)

Sorry for the misleading webrev-mappings in my previous mails. Hope to 
cleared thinks up now (with my wired english ;-) ).

-- Sebastian


[0] Solution 1 
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html
[1] Solution 2 
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html