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

[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.


>> 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?
>
Working on that. Sorry for the annoying ads.
> --Sean
-- Sebastian