Request for Review: Chain more Exceptions (RuntimeException)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Fri Aug 19 14:05:24 UTC 2011


Am 18.08.2011 22:14, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>> Hi,
>>
>> i have created a fix for fixing Exception-Chains in case of an 
>> rethrown RuntimeException.
>>
>> I am not quite sure if this is inside the scope of what i 
>> discussed[0][1] with Joe. But it is
>> fixed in the same manner as the patches there.
>>
>> http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/ 
>>
>>
>> Someone who wants to review / sponsor this?
>>
> I agree with Andrew that this is good clean-up.
>
> I think the changes to 
> src/share/classes/javax/xml/crypto/NoSuchMechanismException.java need 
> closer examination. Removing the 3 methods that it overloads should be 
> okay. Adding @since 1.8 to the existing constructor is not okay 
> Removing the cause field given that it's serializable, I need to 
> remind myself how this works.
OK. We need to change the serialversion. But is this enough? May we 
break applications out there which serialized NoSuchMechanismExceptions 
or extended classes? I have compiled it with no explicit 
serialversionUID and started
./serialver javax.xml.crypto.NoSuchMechanismException
to show the generated serialversionUID. The new is 4170396067457259019L.

Was that the right way to do? Is there an easyier and faster way?
> A minor nit but I notice in many places where you've introduced 
> multicatch that you put the vertical bar at the beginning of the next 
> line whereas I think we've mostly been putting it on the right. In 
> src/share/classes/javax/management/relation/RelationService.java I see 
> you've got both. I don't know if coding conventions have been 
> established on this.
I have updated my webrev to fix serialversionUID and this code-style 
related as Joe suggests its in the other post.
The new webrev is:

http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_55952703809f/
>
> -Alan.
- Sebastian



More information about the core-libs-dev mailing list