| Author: | Kaloian Doganov kaloian@gjt.org |
| Home Page: |
|
| Version: | 1.0 |
| Release Tag: | $ |
| Release Date: | 1999/10/11 21:25:08 |
| JVM Required: | 1.1 |
| License: | Unspecified |
| Categories: | None |
| Requirements: | |
| Dependencies: | No dependencies |
| Externals: | None |
ASSERT and trace messages implementation in Java.
TO DO: Improve documentation.
In order to simulate preprocessor behaviour, we have to force the compiler to include or respectively exclude the assert code from the generated bytecode when we switch a flag. The trick is to use if statement instead of standard method invocation. So, our implementation does not look like: Debug.ASSERT(expression, message), but quite different. And quite ugly, you'll see. :-)
Also, we have more additional parameters to our assert methods. That's why, when assertion is failed, more information is displayed and the code fragment rising the assertion failure is located faster and easyer. It's important issue, since in Java we have no macros and related information about the source filename and line number at runtime. So, we have to display the full classname of the object and the method where assertion is failed. The ASSERT implementation can not recognize the calling class and method by itself, so the programmer (you) have to provide this information as arguments of the assertion. In your method you can insert many ASSERTions, so you have to distinct them with a differed custom messages. If you don't, you can never be sure which assert exactly is failed at runtime. This will made assertion mechanism useless. There is no short equivalents of the assert methods in order to enforce you to use these additional information arguments.
Assert failure listeners are an additional feature that you are not enforced to use. For every thread you can set an assert listener -- a Object that implements the FailureListener interface. When assertion failed, the assert implementation looks for a listener registered for the given thread. If such a listener is present it will be called to handle the failure. Listener can show a dialog (console or GUI) that allows user to decide how to proceed. Options are "Continue" or "Abort". Default behaviour is to abort. Some can implement such a listener that just write failure events in a log and automatically continues execution without user intervention. You can have only one listener per thread.
if (AS.S)ER.T (condition, message, method, this);
Where:
String message to displaythis keyword. For use in static methods, an additional assert methods is provided. public class foo { . . . public void bar() { . . . if (AS.S)ER.T (i > 1, "i must be greater than 1!", "bar()", this); } } See also:
This is a replacement of the standard System.out.println(...) tracing and debugging technique. If you use this MESSAGE implementation instead of System.out.println(...) when you trace and debug, you can ensure that no debug messages will be displayed (or even compiled) into the final release. You just have to switch the MES.S flag.
if (MES.S)AG.E (message, method, this);
if (MES.S)AG.E ("sucessful!", "addItem()", this);