Difference between revisions of "Assertions"

From Suhrid.net Wiki
Jump to navigationJump to search
Line 65: Line 65:
 
* -dsa disables system assertions
 
* -dsa disables system assertions
 
* For packages the ... notation '''has''' to be used.
 
* For packages the ... notation '''has''' to be used.
 +
* The full form can also be used, all the below are valid:
 +
** -enableassertions.-disableassertions
 +
** -enablesystemassertions, -disablesystemassertions
  
 
== Correctly using Assertions ==
 
== Correctly using Assertions ==

Revision as of 02:28, 6 September 2011

Introduction

  • Assertions allow the testing of assumptions about a program.
  • Using assertions allow easy detection of bugs during development without writing exception handlers etc.
  • We "assert" that something will be true at some point in the code. If it is, code keeps running, if it is false, an AssertionError will be thrown.

Example:

//Without assertions

private static void processAge1(int age) {
		if(age > 0) {
			System.out.println("Processing age ...");
		} else {
			System.out.println("Age < 0 !");
		}
	}

//With assertions
	
private static void processAge2(int age) {
		assert age > 0;
		System.out.println("Processing age ...");
}
  • Second version of assert takes a second expression which must return a value (primtive/object). The return value can be anything.
  • This object's string value is added to the assertion error stack trace.
private static void processAge2(int age) {
	assert age > 0 : errorCode();
	System.out.println("Processing age ...");
}
	
private static List<String> errorCode() {
	return Arrays.asList("oops");
}

Compiling with assertions

  • Assertions were introduced as a keyword in java 1.4.
  • Using the source flag - 1.4 onwards trying to use assert as an identifier will result in a compile failure.
  • Trying to use -source 1.3 with assert as an identifier will produce warnings and compilation will fail with assert as a keyword.

Running with assertions

  • Assertions are disabled by default.
  • To enable use the -ea flag.
  • To disable use the -da flag. This is useful to disable assertions for specific classes/packages.

Examples:

  • java -ea -da:net.suhrid.Foo //Enable for all exception of the net.suhrid.Foo class (NOTE THE ':')
  • java -ea:net.suhrid.Bar //Enable only for the net.suhrid.Bar class
  • java -ea -da:net.suhrid.util... //Enable assertions in general, but disable assertions for the net.suhrid.util and all packages below it in the hierarchy.
  • java -ea -da:net.suhrid.util... -ea:net.suhrid.util.Test2 //Disable assertions for the net.suhrid.util and all packages below it in the hierarchy, but enable it for net.suhrid.util.Test2 class.
  • java -da -ea:... Test1 //Disable assertions in general but enable assertions in the unnamed package in the current working directory.
  • -esa enables assertions in system classes (java.lang). This has to be specifically used, with only -ea systemassertions will still be disabled.
  • -dsa disables system assertions
  • For packages the ... notation has to be used.
  • The full form can also be used, all the below are valid:
    • -enableassertions.-disableassertions
    • -enablesystemassertions, -disablesystemassertions

Correctly using Assertions

  • Use assertions to validate arguments to a private method.
  • But not to a public one! Use IllegalArgumentException instead. This is because assertions are optional, so it may or may not work.
  • Similarly dont use assertions to validate command line arguments.
  • Can use assertions in public methods to check for cases that are never supposed to happen. e.g. if we know a switch default must never be reached.
  • Don't use asserts that causes values of variables to change - side effects!