RFR 8009581: Xpathexception does not honor initcause()
Aleksej Efimov
aleksej.efimov at oracle.com
Mon Jun 3 14:18:19 UTC 2013
The next version of webrev:
http://cr.openjdk.java.net/~dmeetry/8009581/webrev.4/
<http://cr.openjdk.java.net/%7Edmeetry/8009581/webrev.4/>
The list of changes:
1. The test was moved to jdk/test/javax/xml/jaxp/XPath/8009579
2. Throw of InvalidClassException was added
3. Two test cases were added:
a) Deserialization of XPathException initialized by ordinary values
and serialized by JDK7 build (normal_jdk7.ser file)
b) Deserialization of "new XPathException(new
Exception()).initCause(null)" XPathException serialized by JDK7 build
(twocauses_jdk7.ser file).
-Aleksej
On 05/31/2013 06:20 PM, Alan Bateman wrote:
> On 31/05/2013 14:39, Aleksej Efimov wrote:
>> Obviously, we can't throw the ISE - it's not described in docs for
>> readObject() method.
>> Exceptions suggested by Jason have the following descriptions:
>> InvalidClassException: Something is wrong with a class used by
>> serialization.
>> StreamCorruptedException: Control information in the stream is
>> inconsistent.
>> I think InvalidClassException more suitable for our case, because we
>> have here the problem with inconsistent state of serialized class,
>> but not the control information in the stream (invalid stream header,
>> invalid type code and etc).
>>
>> Aleksej
> Yes, InvalidClassException would be best.
>
> I see you've added a serialization/deserialization test (thanks) but
> it wouldn't have caught this. What would you think about serializing a
> few XPathException instances with a jdk7 build and use the byte stream
> in the test to check that they are handled correctly. That would give
> more confident that there aren't any other holes.
>
> -Alan
More information about the core-libs-dev
mailing list