Design Pattern in ActionScript 3.0 – I

An assertion is a boolean expression that a developer specifically proclaims to be true during program runtime execution. The simple idea of using assertions can have an unexpected influence on a software program’s design and implementation. In this article I cover the mechanics of using the new assertion facility introduced in J2SE.

Assertions let you test your assumptions during development, but the assertion code basically evaporates when the program is deployed, leaving behind no overhead or debugging code to track down and remove.

Suppose you assume that a number passed into a method (say, assertMethod()) will never be negative. While testing and debugging, you want to validate your assumption, but: you don’t want to have to strip out print statements, runtime exception handlers, or if/else tests when you’re done with development. But leaving any of those in is, at the least, a performance hit. Assertions to the rescue! Check out the following code:

private void assertMethod(int number) {
if (number>= 0) {
useNumber(number+ x);
} else {  // number must be < 0
// This code should never be reached!
System.out.println(“ooh.. numberis a negative number! ”
+ number);
}
}

Because you’re so certain of your assumption, you don’t want to take the time (or program performance hit) to write exception-handling code. And at runtime, you don’t want the if/else either because if you do reach the else condition, it means your earlier logic (whatever was running prior to this method being called) is flawed.

Assertions let you test your assumptions during development, but the assertion code basically evaporates when the program is deployed, leaving behind no overhead or debugging code to track down and remove. Let’s rewrite assertMethod() to validate that the argument was not negative:

private void assertMethod(int number) {
assert (number>=0);   // throws an AssertionError
// if this test isn’t true
useNumber(number+ x);
}

Not only do assertions let your code stay cleaner and tighter, but because assertions are inactive unless specifically “turned on” (enabled).

Assertions work quite simply. You always assert that something is true. If it is, no problem. Code keeps running. But if your assertion turns out to be wrong (false), then a stop-the-world AssertionError is thrown (that you should never, ever handle!) right then and there, so you can fix whatever logic flaw led to the problem.

Assertions come in two flavors:

1.  assert expression1;

private void assertA()
assert (y > x);
// more code assuming y is greater than x
}

2. assert expression1 : expression2;

private void assertA() {
assert (y > x): “y is ” + y + ” x is ” + x;
// more code assuming y is greater than x
}

The difference between the two is that the second flavor adds a second expression, separated from the first (boolean expression) by a colon, this expression’s string value is added to the stack trace. Both flavor throw an immediate AssertionError, but the second flavor gives you a little more debugging help while the first flavor simply tells you only that your assumption was false.

Enabling Assertions:

You can enable assertions at runtime with
java -ea com.geelcsanonymous.TestClass    or
java -enableassertions com.geeksanonymous.TestClass

Disabling Assertions :
You must also know the command-line switches for disabling assertions,
java -da com.geeksanonymous.TestClass   or
Java -disableassertions com.geeksanonymous.TestClass

Enabling Assertions in Eclipse:

Basically, you want to pass an argument (-ea) to the VM. How to do this might vary depending on your version of Eclipse, but here’s how it works in Eclipse Europa…
# Open the Run Dialog (this should be an option under the “Run” menu).
# Click on the tab, “(x)= Arguments.”
# In the field for “VM arguments,” enter -ea to enable assertions.
# Click on the “Apply” button.

Tags: Java, SCJP