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

Aleksej Efimov aleksej.efimov at oracle.com
Sat May 25 08:37:35 UTC 2013

David, Jason, Thank you for your comments and suggestions. They all were taken in account and as a result - the new webrev: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.2/

On 05/24/2013 08:26 AM, David Holmes wrote:

On 22/05/2013 2:51 AM, Jason Mehrens wrote:

Aleksej,

Actually, the readObject calls the super.initCause, because there is no initCause in XPathException. I would think that subclasses of XPE will see calls to this.initCause from readObject. That wouldn't have happened prior to this change. I think this is why super.initCause() (or super.getCause()) must be called here. If you invoke this.xxx() then you may well be invoking a subclass specialization and you don't know what it will do. Agree with that, we want to call the specific 'initCause', not the subclass specialization.

About 'super.getCause() == null' check: yes it can be done in such way. In current version I caught the IllegalStateException to correctly process the situation when the cause was already initialized. I think you'll always have to catch ISE. If super.getCause is not null you know initCause will fail. I would think it would be cheaper to null check than to fillStackTrace. But, I haven't tested that. I think readObject only needs to account for deserializing an older version of the exception which will have a non-null local cause, but Throwable.cause is null. That should be rare. The common case would be deserializing the new form, in which case initCause would fail. So I agree with Jason that checking super.getCause() is more efficient than always calling initCause. Also agree, the ' super.getCause() == null' check added to readObject. David Jason

Aleksej

More information about the core-libs-dev mailing list