7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException
sebastian.sickelmann at gmx.de
Sat Oct 29 11:17:41 UTC 2011
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
> 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 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 for jx/x/s-Exceptions that implement
> Solution 3 for comparision.
More information about the core-libs-dev