Code review request for 6935997 "Please add a nested throwable constructor to AssertionError"

David Holmes David.Holmes at oracle.com
Fri Jun 4 10:27:45 UTC 2010


Bruce Chapman said the following on 06/04/10 18:46:
> Is this a first step to fixing the compiler error where the JLS says the
> (2nd) expression in an assert statement is converted to String and a new
> AssertionError is constructed with that STRING as the argument, and that
> AssertionError is thrown? (my paraphrase)
> 
> http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.10
> 
> BUT
> 
> assert false : new Throwable();
> 
> has evidence to suggest that this (JLS spec) is not currently the case,
> since the AssertionError thrown has a cause, and therefore the Throwable
> was not converted to a String before being passed to the AssertionError
> constructor.

I reported this back in 2005 :) It's considered a spec bug. See 6302175 
- Second argument of assert statement not always converted to a String

Cheers,
David Holmes

> You can get away with having the AssertionError constructor do the
> conversion in all other cases (which reduces the amount of bytecode
> emitted for each assert statement), but this currently does not work for
> a Throwable.
> 
> So it might be better for the 1st argument of the new method to be
> Object, and having almost the same semantics as the current single
> Object arg constructor - except it would NOT treat the first arg as the
> cause when it is a Throwable.
> 
> This way the assert statements could for (other than primitives) be
> compiled to call the 2 arg constructor with a null value for second arg
> and thus become indistinguishable (other than bytecode inspection) from
> something that did exactly as the JLS says.
> 
> yeah - call me pedantic if you want  :-)
> 
> Bruce
> 
> 
> 
> Joe Darcy wrote:
>> Hello.
>>
>> Please review my fix for
>>
>> 6935997 "Please add a nested throwable constructor to AssertionError"
>> http://cr.openjdk.java.net/~darcy/6935997.0/
>>
>> Thanks,
>>
>> -Joe
>>
> 
> 



More information about the core-libs-dev mailing list