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
cause accordingly.
-Joe
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.
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
