7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException

[Sebastian Sickelmann]

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