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