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
