Am 28.09.2011 06:36, schrieb Sebastian Sickelmann:
Am 27.09.2011 17:38, schrieb Sean Mullan:
On 9/24/11 5:55 AM, Sebastian Sickelmann wrote:
Am 23.09.2011 20:54, schrieb Sean Mullan:
On 9/17/11 3:09 PM, Sebastian Sickelmann wrote:
i have updated the webrev [0].
But i think that L69 and L72 of the test should be changed to
checkMutable and the implementation of the exceptions accordantly.
That's an interesting question. The current implementation in your
code is
consistent with java.lang.ClassNotFoundException. I'm curious as to
why they
disallowed initCause to be called even if they were created using the
constructors without Throwables. Any idea? Was this discussed in
the other lists?
I don't know. I can't find anything in the archives (don't know in
which
time i must search; The commit in ClassNotFoundException is prior
rev 0)
@core-libs-dev: Does someone remember why this solution was preferred
for ClassNotFound?
See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385429
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.
For javax/xml/crypto i would change it to my suggestion (to L69 and
L72)
above to not break behavior for JSR105. On the other side it would be
nice to have a common behavoir on this for all Exceptions in JDK.
There are 2 solutions that sound reasonable for me:
1. Preventing initCause when cause is given. And allowing initCause
once
(if created with an ctor without cause).
2. Preventing initCause in every exception class that has the 4
standard
ctors. Only for those Exceptions without the "ctors with cause" the
initCause can be called.
I think all exceptions that had no chaining before Throwable
introduces it actually follow
solution 1, where some of the Exceptions don't have a ctor with a cause.
All those who had chaining before (ex. ClassNotFoundException)
actually follow
solution 2.
But whats the correct solution?
I like both.
No.1 is nearer to the behavoir we actually have and is more flexible
than No.2.
No.2 is more "secure". You cannot "inject" an cause in ex. after you
catches the exception. But you must have the cause to initialize it
before you create the exception, this is slightly more inflexible, even
if i think this flexibility is not needed anywhere.
If i think longer about it, i like No.2 a bit more. It is nearer what
i would expect how a exception should react on giving a cause.
[0]
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_3
-- Sebastian
Any comments / progress on this?
Just a couple of minor comments on the test:
- the copyright date should only include 2011
- some minor typos (line number in []):
[26] s/in/is
[43] s/validating/validate
[98] s/checkImutable/checkImmutable
Updated webrev:
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_4
BTW, the popup ads on this site are very annoying. Can you move your
webrev to a
different site?
Ok. Done this. Sorry for the annoying ads, again.
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html
Working on that. Sorry for the annoying ads.
--Sean
-- Sebastian
