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