Updated ARM Spec

[Rémi Forax]

Le 23/08/2010 12:29, David Holmes a écrit :
> Rémi Forax said the following on 08/23/10 20:23:
>> Le 23/08/2010 12:09, David Holmes a écrit :
>>> Rémi Forax said the following on 08/23/10 20:06:
>>>> You can explicitly call setStackTrace() on a shared immutable 
>>>> exception, hence there is a problem.
>>>> addSupressedExceptions() will have the same issue.
>>>
>>> I stand corrected. The Java side of the code couldn't care less 
>>> about the VM level backtrace - it just installs a Java array. :(
>>>
>>>> I think the fix is to:
>>>> - silently discard the stack trace taken as argument of 
>>>> setStackTrace() if the cause is 'null' (or not 'this')
>>>> - silently don't register suppressed-exceptions if cause is 'null'
>>>
>>> I think the Java code should be able to recognize a Throwable 
>>> instance that should not allow these things to be set, and simply 
>>> ignore the request. However that is a change in the spec for 
>>> setStackTrace.
>>
>> Yes, setStackTrace() can 'not succeed'.
>> And the way to recognize such Throwable instance is to check is the 
>> field 'cause' is null.
>
> Except if someone invokes setCause(null).

setCause(null) should set the field cause to this.
For Throwable(null) and Throwable(message, null), null should also be 
escaped.

The other solution is to use the field suppressedExceptions with the 
invariant that if
it's null, it's an immutable shared exception.

>
> By the way, probing further, the non-OOME shared pre-allocated 
> instances do not guard themselves against fillInStackTrace being 
> invoked upon them. That is arguably an additional bug. I say arguably 
> simply because in the circumstances under which those other exceptions 
> are thrown, having a misleading stacktrace is probably the least of 
> the application's worries.

yes, you right.

>
> David

Rémi

>
>
>>> Suppressed-exceptions could then be modelled like backtrace support 
>>> - an optional facility generally used but ignored for the 
>>> pre-allocated immutable instances.
>>
>> Yes, and the spec must be also updated accordingly.
>>
>>>
>>> David
>>
>> Rémi