On 12/2/11 12:54 AM, Sebastian Sickelmann wrote:
> 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.
Right, and I think some of those cases are legitimate. I have seen exception
handling code which performs cleanup in a finally block, and if an exception is
thrown in the finally block, it catches that exception, but sets the cause of
the exception to the original exception. This would not be possible with
solution 3 if there was already a ctor that had a cause parameter. For example,
I have seen code like this:
Throwable t = null;
try {
...
} catch (Exception x) {
t = x;
} finally {
try {
...
} catch (FooException e) {
if (t != null)
e.initCause(t);
throw e;
}
}
> 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)
My opinion is that the potential compatibility issues, as well as having awkward
workarounds for the case above outweigh the advantages of making this change. So
I am not in favor of solution 3. But that's just my opinion, others may feel
differently.
> Sorry for the misleading webrev-mappings in my previous mails. Hope to
> cleared thinks up now (with my wired english ;-) ).
Ok, so I think we're down to 2 solutions. Give me some more time to look them
over more carefully and get back to you.
--Sean
>
> -- 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
