Code review request for 6935997 "Please add a nested throwable constructor to AssertionError"
joe.darcy at oracle.com
Mon Jun 7 13:14:28 PDT 2010
Bruce Chapman wrote:
> 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)
No, just wanted to address this minor flaw in the set of constructors
for this error :-)
As David noted, the intended fix to the JLS issue is to change the JLS
to match the long-standing behavior of the implementation. The
implementation checks if the 2nd arg is a Throwable and, if so, sets the
> 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
> 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 :-)
> Joe Darcy wrote:
>> Please review my fix for
>> 6935997 "Please add a nested throwable constructor to AssertionError"
More information about the core-libs-dev