7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException
sebastian.sickelmann at gmx.de
Fri Sep 30 18:15:25 UTC 2011
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 .
>>>>>> 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
>>> 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
> 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
>>> 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
>>> (if created with an ctor without cause).
>>> 2. Preventing initCause in every exception class that has the 4
>>> 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.
>>>>>> -- 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 ):
>>>>  s/in/is
>>>>  s/validating/validate
>>>>  s/checkImutable/checkImmutable
>>> Updated webrev:
>> 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.
> Working on that. Sorry for the annoying ads.
> -- Sebastian
More information about the core-libs-dev