RFR 8009581: Xpathexception does not honor initcause()

[Aleksej Efimov]

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