RFR 8009581: Xpathexception does not honor initcause() (original) (raw)

Aleksej Efimov aleksej.efimov at oracle.com
Mon Jun 3 14🔞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