[1083] in java-interest
Re: Assertions in Java
daemon@ATHENA.MIT.EDU (Jeremy Fitzhardinge)
Fri Aug 18 03:55:47 1995
From: "Jeremy Fitzhardinge" <jeremy@suede.sw.oz.au>
Date: Fri, 18 Aug 1995 14:51:36 -0500
In-Reply-To: "John D. Mitchell" <johnm@CSUA.Berkeley.EDU>
"Re: Assertions in Java" (Aug 17, 2:56pm)
To: "John D. Mitchell" <johnm@csua.berkeley.edu>,
andycarlson@attmail.com (Andrew Carlson)
Cc: java-interest@java.sun.com
> > >[...if + flag vs assert...]
> [...]
> > Yep, that should work. I use ASSERT a lot in C++, so think I would
prefer
> > a bit of 'syntactic sugar' to make them a bit easier to write (and
read)
> > though.
>
> Can you think of way to do this without going to the (unpleasant) extreme
> of a pre-processor?
>
> The only thing that immediately pops to mind is assert/pre/post blocks
(ala
> the static and synchronized blocks).
How about adding an "final void assert(bool, String)" method to
Object? If the expression is false, then it can print the String and
throw an AssertionFailedException. If that isn't caught, the runtime
will print a stack backtrace (or should), complete with line number
detail.
If you want to disable assertions, you can either use an Object with a
noop assert, or get the runtime to remove calls to Object.assert().
This would still evaluate the assertion condition, but it may be
possible for the runtime to optimise it away if the value it calculates
is not used, and it doesn't have any side-effects (right? noone uses
asserts with side-effects, do they?).
If you keep the calls in source to the form
assert(thingy, "woozle has collapsed spontaneously")
then it could later become a keyword and get more compiler support.
The only way this doesn't behave like a "real" assert is that it doesn't
print the expression it's testing, but that's often not that useful...
J
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
