Request for review Remove "private" cause in jdk exceptions
sebastian.sickelmann at gmx.de
Fri Aug 26 04:15:17 PDT 2011
Am 26.08.2011 09:22, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>> OK. Webrev is there:
>> Can someone review this?
> I think this one will require careful review and I'm not even sure
> that it's worth it. Using serialPersistentFields and overriding the
> readObject/writeObject method is the right thing for this kind of
> issue but it's bringing complexity that hardy seems worth it.
As Peter noted in his reply there is another solution to handle chaining
as introduced in Throwable for Exceptions that already has an own cause
Like in InvocationTargetException . The Change is much simple and
introduces much less complexity, for the cost of one additional
reference to the cause (which should be no problem).
> There are a few awkward issues in here. I have to admit that I don't
> know, without checking, what the deal is with APIs that continued life
> as standalone JSRs after going into Java SE. I also suspect that some
> of these changes have subtly changed the behavior of a few of the
> exceptions. On RemoteException the patch removes a public field which
> we can't do. I think the other clean-up patches that you have posted
> here in the last week or two are good and we should move forward on them.
I will continue on the other issues too. Thanks for reviewing/supporting
on my CRs. (Does CR mean Change Request???)
More information about the core-libs-dev