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

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

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

--Sean