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
