Request for Review: Chain more Exceptions (RuntimeException)
sebastian.sickelmann at gmx.de
Fri Aug 19 07:05:24 PDT 2011
Am 18.08.2011 22:14, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>> 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 with Joe. But it is
>> fixed in the same manner as the patches there.
>> 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
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:
More information about the core-libs-dev