RFR 8009581: Xpathexception does not honor initcause()

David Holmes david.holmes at oracle.com
Fri May 24 04:26:10 UTC 2013


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.

>> 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.

David


> Jason 		 	   		
>



More information about the core-libs-dev mailing list