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_4/index.htm
<http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html>
The problem with Solution 3 is that bahavoir compatibility is not given
and some code may break.
-- Sebastian
Am 02.10.2011 21:49, schrieb Sebastian Sickelmann:
Am 01.10.2011 18:19, schrieb Sean Mullan:
On 9/30/11 2:15 PM, Sebastian Sickelmann wrote:
I think I know the reason. If you allow initCause to be called when a
cause is
not initially provided, then getCause will still return null, which
seems wrong.
getCause() of Throwable and all classes that doesn't had a chaining
before
Throwable introduces it, doing this excact this way. Whats wrong on
this?
return (cause==this ? null : cause); // Where the initial
value(uninitialied) of cause is this.
Does this make sense? I actually not sure i understand you right.
The following code:
KeySelectorException kse = new KeySelectorException("foo");
kse.initCause(new Exception("bar"));
System.out.println(kse.getCause());
prints null as the cause, even though initCause was subsequently
called. Do you
see my concern?
This is one of the places in code which must be changes to match the
initCause behavoir of Throwable.
I have done it here:
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_5/index.html
But is this the best way? Or should we just follow the other
Exceptions and start an seperate discussion on this with core-libs-dev?
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html
Thanks!
--Sean
