The difference between the checked and the non-checked assertions for the developer is that they must explicitly handle any exceptions raised by the CheckedAssertion class, whereas they can choose to ignore the fact that an exception may be raised by the Assertion class.

In Java, a package is an associated group of classes and interfaces [1]. We have defined a new package assertion which holds the four classes listed above. Other classes can then use these four by importing the assertion package. An example of how these classes are used is presented in Listing 1.

This example creates a simple class Example which uses the Assertion class to handle the result of checking the relationship between a and b. The result of running this application is presented in Listing 2.

We could have caught the AssertionException within a try{} catch{} block. This construct allows a piece of code to be wrapped up within a try block. The try block indicates the code which is to be monitored for the exceptions listed in the catch expressions. The catch expressions can then be used to indicate what to do when certain classes of exception occur; for example, "resolve the problem" or "generate a warning message", etc. If no catch expressions are included the throws clause must be handled by the method definition. For example:

try { e.test(1, 2);
e.test(2, 1);
}
catch (AssertionException e) {
System.out.println("First parameter larger than second");
}

This would have allowed us to respond in an appropriate manner. Below we examine the implementation of the Assertion and AssertionException classes and their checked counterparts.

Exceptions in Java
In Java, (almost) everything is an object; therefore, exceptions are objects as well. All exceptions must extend the class Throwable or one of its subclasses [4].

The class Throwable has two subclasses, Error and Exception. Errors are unchecked exceptions. These are exceptions which your methods are not expected to deal with. The compiler therefore does not check that the methods can deal with them. In contrast, most exceptions (but not RuntimeException and its subclasses) below the class Exception are checked exceptions. These exceptions must be dealt with by your methods. The compiler thus checks to see that methods throw only exceptions which they can deal with (or are passed up to other methods to handle). For example, if we wished to raise an ArithmeticException, for a divide by zero error then we would write:

throw new ArithmeticException("Division By Zero");

In Java, you are not limited to system-provided exceptions; it is also possible to provide user-defined exceptions. This can be very useful as such an approach can allow the developer to have more control over what happens in particular circumstances. To do so, a developer must subclass the Exception class or one of its subclasses.

Assertions in Java
The Assertion class
The Assertion class (a direct subclass of Object) makes two methods publicly available for handling boolean expressions. These are:

The second method is really a convenience method which repeatedly calls the first method on each element in the array.

The implementation of the assert(boolean bool) method is relatively straightforward. The method checks whether the boolean value is false or not. If it is false an exception is raised. The assert(boolean bools []) method simply calls the previous method iteratively (see Listing 3).

Switching Assertion Checking Off
In the released version of the system, the assertion checks may waste processing time. they could therefore be replaced by a null version of the method:

public static void assert (boolean bool) throws AssertionException {
return true;
}

As Java dynamically loads the appropriate .class file at runtime, we could distribute the final version of the system with an Assertion.class file based on the above implementation of assert. We would therefore not even need to recompile the system being released.

The overhead of the extra method dispatch is relatively small; of course, if it is still significant we could write a utility to find the senders of the assert method and to comment out the assertion statements.

The AssertionException class
The AssertionException class is a subclass of the RuntimeException class as illustrated in Figure 1. The definition of the AssertionException class is provided in LIsting 4. Note that it provides two constructors which are used to initialize the string displayed to the user.

CheckedAssertion and CheckedAssertionException
These classes are essentially the same as the Assertion and AssertionException classes except that the CheckedAssertion class throws the CheckedAssertionException and the CheckedAssertionException extends the Exception class (as shown in Figure 1). For the developer, the difference between the two types of assertion checking is that any exceptions raised by the CheckedAssertion class must be handled explicitly; they can not simply be propagated out of the program.

The advantage is that the developer using the assertions can decide how much control to give to the user of a component. If they wish, they can force that user to handle the exception and thereby allow them to take charge of any problems which occur. This can result in code which is more resilient to erroneous situations.

For completeness, the two classes are presented in Listings 5 and 6.

Analysis
Design methods Using Assertions
Assertions are particularly useful for testing pre-conditions, post-conditions and class invariants. The Syntropy design method makes extensive use of such assertions [6]. It would therefore be possible to use the assertions identified during the design as the basis of the assertions to place in the Java code.

JavaBeansª
The use of assertions could be extremely useful when working with JavaBeans (the Java component model). In such situations developers produce reusable components which will be used by developers in many different ways. By using assertions, developers can ensure that the state of the Bean at any time is correct. If the state is not correct then they can take appropriate action. The assertions can therefore be used as guards against inappropriate states, parameters, etc.

Shortcomings
The simple approach to inserting assertions into Java code described here cannot provide the following, more sophisticated types of assertions:

void swap (SomeType x, SomeType y) {
SomeType z;
z = x;
x = y;
y = z;
}

One might want to assert, just before the method returns, that the new value of x is equal to the old value of y and the new value of y is equal to the old value of x. This is not possible with our assertion mechanism. Assertion mechanisms for which this is possible have additional syntax which allows the "before and after" values of variables to be distinguished.