7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException (original) (raw)
Sebastian Sickelmann sebastian.sickelmann at gmx.de
Sat Oct 29 11:17:41 UTC 2011
- Previous message (by thread): 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException
- Next message (by thread): hg: jdk8/tl/jdk: 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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). 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/70118044/index.html [1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20111029/4bb6df40/attachment.htm>
- Previous message (by thread): 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException
- Next message (by thread): hg: jdk8/tl/jdk: 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]