in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 21 22 23 24 25 26 < 27 > 28 29 30 31 32 33 .. 166 >> Next

Many developers do not understand why or how to use assertions, and this has caused them to go widely unused. Some developers use them improperly, causing them to be ineffective or counterproductive to the development effort.
How to Use Assertions
When writing code, we make assumptions all of the time. Assertions are meant to capture those assumptions in the code. By capturing those assumptions, you move closer to implementing a significant concept in quality software: design by contract.
60 Item 7
Design by Contract holds there are three concepts embodied in any piece of code: preconditions, postconditions, and invariants. Preconditions involve the assumptions about the state prior to the execution of code. Postconditions involve the assumptions about the state after the execution of the code. Invariants capture the underlying assumptions upon which the execution occurs.
Consider the following method signature:
public String lookupPlayer (int number)
In this method, I provide a service to look up a player by his number. In explaining this signature, I have already specified a set of assumptions. The first assumption is players do not have numbers greater than 99 (they don't fit on a jersey well, and most teams don't have more than 100 players on their roster). Also, players do not have negative numbers either. Therefore, the preconditions are that we have a number provided that is less than or equal to zero and less than or equal to 99. An invariant is to assume that the list of players and numbers actually exists—that is, it has been initialized and is properly available (note that this action is subject to its own set of assumptions). The assumption on the postcondition is that there will be an actual String value returned from the method (and not a null).
How many times have you seen a problem with the code being debugged by a set of System.out.println() statements? This is because, essentially, the developer is going back in and creating visibility to check against assumptions that are made in writing the code. This can be relatively painless and easy for the developer who wrote the code—at the time he or she wrote the code. However, this becomes quite painful for others who may not understand what is going on inside the code.
Assertions can be thought of as automatic code checks. By writing assertions, you capture your assumptions, so that an error will be thrown at the incorrect assumption when the code is running. Even if a bug occurs that does not throw an Assertion-Error, they still enable the developer to eliminate many possible assumptions as causes of error.
There are really four conditions you should meet in order to determine that you do not need to use assertions:
¦¦ You wrote and maintain all of the code in question.
¦¦ You will always maintain every piece of that code.
¦¦ You have analyzed to perfection all of the different scenarios that your code may experience through some method like a formal code proof.
¦¦ You like and can afford to operate without a net.
With the exception of the last condition, if you have done all of these, you have already realized that you need some assertionlike capability. You probably have already littered your code with System.out.println() or log() statements trying to give yourself places to start like that demonstrated in Listing 7.1.
My Assertions Are Not Gratuitous! 61
01 package org.javapitfalls.item7;
03 public class AssertionExample {
05 public AssertionExample() { }
07 private void printLeague (String abbreviation) {
09 if (abbreviation.equals("AL")) {
11 System.out.println("I am in the American League!");
13 } else if (abbreviation.equals("NL")) {
15 System.out.println("I am in the National League!");
17 } else {
19 // I should never get here...
20 assert false;
22 }
23 }
25 public static void main (String [] args) {
27 String al = "AL";
28 String nl = "NL";
29 String il = "IL";
31 AssertionExample myExample = new AssertionExample();
33 myExample.printLeague(al);
34 myExample.printLeague(il);
35 myExample.printLeague(nl);
37 }
39 }
Listing 7.1
So, we compile this code and the following happens: C:\pitfallsBook\#7>javac warning: as of release 1.4, assert is a keyword, and may not be used as an identifier assert false ; not a statement assert false ;
62 Item 7 ';’ expected assert false ;
2 errors
1 warning
What happened? I thought assertions were supported in JDK 1.4! I am using JDK 1.4. Well, as it turns out, for backward compatibility purposes, you have to specify a flag in order to compile source with assertions in it.
So, you would want to compile it like this instead:
javac -source 1.4
Now that I have successfully compiled my example, here is what I do to run it:
C:\pitfallsBook\#7>java -cp . org.javapitfalls.item7.AssertionExample
Previous << 1 .. 21 22 23 24 25 26 < 27 > 28 29 30 31 32 33 .. 166 >> Next