The general form of the “switch” statement is impossible to show in any meaningful form in a syntax diagram with less than about two dozen production rules. That tells you something about how badly designed the statement is right there. If you look at Kernighan and Ritchie’s C book, The C Programming Language, you’ll note that even they were not up to the task of showing the syntax in any better way than this:

switch ( Expression ) Statement

Neither has any other C book since. Ignoring syntax diagrams, the switch statement is a poor man’s “case” statement. It causes control to be transferred to one of several statements depending on the value of the Expression, which must be of type char, byte, short, or int. It generally looks like this:

switch (Expression) { 
   case constant_1 : Statement; break; 
   case constant_5 : 
   case constant_3 : Statement; break; 
        ... 
   case constant_n : Statement; break; 
         default : Statement; break; 
    } 
    

JDK 1.4 has a compiler option to check for and warn about switch fall-through. Use this command line:

javac -Xswitchcheck filename.java 

for( i=0; i<100; i++ ) { ... 

A typical infinite loop will look like:

for (;;) 

for( int i=0; i<100; i++ ) { ... 

This is a nice feature created for the convenience of the programmer.

for(i=0,j=0; i<100; i++, j+=2 ) { ... 

The “while” statement looks like this:

The “do while” statement looks like this:

There may be “continue” statements in a loop. These look like:

Continue statements occur only in loops. When a continue statement is executed, it causes the flow of control to pass to the next iteration of the loop. It’s as though you say, “Well, that’s it for iteration N; increment the loop variable (if this is a “for” loop), do the test, and continue with iteration N+1.”

The “continue Identifier” form is used when you have nested loops, and you want to break out of an inner one altogether and start with the next iteration of the outer loop.

The loop which you want to continue is labeled at its “for” statement with the matching identifier, and it does the same trick. Namely, that’s it for iteration N of the labeled loop; increment the loop variable (if this is a “for” loop), do the test, and continue with iteration N+1. You continue with the next iteration, even though the label is (confusingly) at the beginning, rather than labeling, say, the end of the loop. Here is an example “continue” statement:

There may be “break” statements in a loop or switch. These look like this:

break; 

Or they look like this:

break identifier; 

Break is a more dramatic version of continue. Break with no identifier causes control to pass to just after the end of the enclosing “for, do, while,” or “switch” statement. The loop or switch statement is “broken out of.” Break with no identifier can appear only in a statement by virtue of the whole thing being nested in an iteration or switch statement. You will break to the end of the iteration or switch, not the statement it’s immediately nested in.

If an identifier is included, it must be an identifier matching the label on some enclosing statement. The enclosing statement can be any kind of statement, not just an iterative or switch statement. In other words, it’s OK to break out of any kind of enclosing block as long as you explicitly indicate it with a label. In practice, it’s almost always a loop or switch that you break out of, not an if or block. Again, there is the slightly confusing feature that statements are labeled at their beginning, but “break” causes you to jump to their end. Here is an example:

There is a reserved word “goto” in Java, but there is no goto statement. The designers grabbed the keyword to ensure that no one uses it as a variable name in case it later turns out to be convenient to support (perhaps for automatically generated code).

How to Look at Bytecode Instructions for a Statement

You can look at the Java code output by the compiler by using the javap command, like this:

javap -c  class 

The javap command is an abbreviation for “java print.” It can be instructive and fun to look at the bytecode output for various Java statements. You can find answers to questions about the code something is compiled into.

Javap will also tell you the sourcefile from which the class came, which is sometimes a useful check that you are executing the code you want. Here’s the result of running javap on the WarningWindow class we compiled in the last chapter:

javap -c WarningWindow 
Compiled from example.java // first it lists the class API 
class WarningWindow extends java.awt.Window {
    WarningWindow(java.awt.Frame); 
    public void setSize(int, int); 
} 

Method WarningWindow(java.awt.Frame) // really a constructor 
   0 aload_0 
   1 aload_1 
   2 invokespecial #6 <Method java.awt.Window(java.awt.Frame)> 
   5 aload_0 
   6 getstatic #7 <Field java.awt.Color red> 
   9 invokevirtual #8 <Method void setBackground(java.awt.Color)> 
  12 return 

Method void setSize(int, int) 
   0 iload_1 
   1 i2d 
   2 ldc2_w #10 <Double 1.5> 
   5 dmul 
   6 d2i 
   7 istore_3 
   8 iload_2 
   9 i2d 
  10 ldc2_w #10 <Double 1.5> 
  11 ... etc 

You can decode the bytecode instructions by looking at the JVM specification at java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html.

Exceptions are for changing the flow of control when some important or unexpected event, usually an error, has occurred. They divert processing to a part of the program that can try to cope with the error, or at least die gracefully. The error can be any condition at all, ranging from “unable to open a file” to “array subscript out of range” to “no memory left to allocate” to “division by zero.” Java exceptions are adapted from C++, which itself borrowed them from the research language ML. Like C and C++, ML (Meta Language) was developed at Bell Labs. Java exception terminology is presented in Table 7-1.

An exception can be set in motion explicitly with the “throw” statement, or implicitly by carrying out some illegal or invalid action. The exception then diverts the normal flow of control (like a goto statement).

If the programmer has made provision, control will transfer to a section of the program that can recover from the error. That section can be in the same method, in the method that called the one where the exception occurred, or in the one that called that method. If no catch clause is found there, the thrown object continues up the stack of calls that were made at runtime. You might want to refresh your memory on how the stack is used to keep track of method invocations by looking at the diagram that was presented back in Chapter 3.

If the thrown object gets to the top where your program execution started, and no handler for the exception has yet been found, then program execution will cease with an explanatory message.

Therefore, the places that you can jump to are strictly limited. You must even explicitly stipulate, “In this block, I will listen for and deal with this type of exception.”

Exceptions are caused in one of two ways: the program does something illegal (common case), or the program explicitly generates an exception by executing the throw statement (less common case). The throw statement has this general form:

throw   ExceptionObject; 

The ExceptionObject is an object of a class that extends the class java.lang.Exception.

Here is a simple program that causes a “division by zero” exception:

class melon {
   public static void main(String[] a) {
      int i=1, j=0, k; 

      k = i/j;    // Causes division-by-zero exception 
   } 
} 

Compiling and running this program gives this result:

> javac melon.java 
> java melon 
     java.lang.ArithmeticException: / by zero 
           at melon.main(melon.java:5) 

There are a certain number of predefined exceptions, like ArithmeticException, known as the runtime exceptions. Actually, since all exceptions are runtime events, a better name would be the “irrecoverable” exceptions. They mean “runtime” in the sense of “thrown by the runtime library code, not your code.”

Runtime exceptions contrast with the user-defined exceptions which are generally held to be less severe, and in some instances can be recovered from. If a filename cannot be opened, prompt the user to enter a new name. If a data structure is found to be full, overwrite some element that is no longer needed. You don’t have to make provisions for catching runtime exceptions. You do have to make provisions for catching other exception types

Some Predefined Exceptions and How They Extend More Basic Classes

The names are intended to suggest the condition each represents. The source files for these can be found in $JAVAHOME/src/java/lang.

Why is there a class “Throwable?” Why doesn’t Exception extend Object directly? The reason is that there is a second class called “Error,” which also extends Throwable. In other words, both Exceptions and Errors can be thrown, but Errors are not meant to be caught. They usually indicate some catastrophic failure. Typical Errors are: LinkageError, OutOfMemoryError, VerifyError, and IllegalAccessError. Throwable is the common superclass for all.

User-Defined Exceptions. Here is an example of how to create your own exception class by extending System.exception:

class OutofGas extends Exception {} 

class banana {
        : 

      if (fuel < 0.1) throw   new OutofGas(); 
} 

Any method that throws a user-defined exception must also either catch it or declare it as part of the method interface. What, you may ask, is the point of throwing an exception if you are going to catch it in the same method? The answer is that exceptions don’t reduce the amount of work you have to do to handle errors. Their advantage is they let you collect it all in well-localized places in your program so you don’t obscure the main flow of control with zillions of checks of return values.

Of the types of statements we defined at this chapter’s opening, here is where guarding statements fit in.

Here is the general form of how to catch an exception:

The “try” statement says, “Try these statements and see if you get an exception.” The “try” statement must be followed by at least one “catch” clause or the “finally” clause.

Each catch says, “I will handle any exception that matches my argument.” Matching an argument means that the thrown exception could legally be assigned to the argument exception. There can be several successive catches, each looking for a different exception. Don’t try to catch all exceptions with one clause, like this:

catch (Exception e) { ... 

That is way too general to be of use and you might catch more than you expected. You are better off letting the exception propagate to the top and give you a reasonable error message.

The “finally” block, if present, is a “last chance to clean up” block. It is always executed—even if something in one of the other blocks did a “return!” The “finally” block is executed whether an exception occurred or not and whether it was caught or not. It is executed after the catch block, if present, and, regardless of the path taken, through the try block and the catch block.

The “finally” block can be useful in the complete absence of any exceptions. It is a piece of code that is executed irrespective of what happens in the “try” block. There may be numerous paths through a large and complicated “try” block. The “finally” block can contain the housekeeping tasks that must always be done (counts updated, locks released, and so on) when finishing this piece of code.

Here is an example of an exception guarding statement in full adapted from the window toolkit code:

public void printComponents(Graphics g) {
     // ... some code omitted ... 
     Graphics cg = g.create(); 
     try {
          cg.clipRect(i.left, i.top, vs.width, vs.height); 
          cg.translate(p.x, p.y); 
          c.printAll(cg); 
     } finally {
          cg.dispose(); 
     } 
} 

The method prints components in a scrolling window. It puts a pixel representation of the components onto g, the Graphics context. Graphics contexts are an operating system concept, not a Java concept.The finally clause was designed for recycling (releasing) resources like this.

After the whole try ... catch ... finally series of blocks are executed, if nothing else was done to divert it, execution continues after the last catch or finally (whichever is present). The kinds of things that could make execution divert to elsewhere are the regular things: a continue, break, return, or the raising of a different exception. If a “finally” clause also has a transfer of control statement, then that is the one that is obeyed.

We mentioned before that “matching an argument” means that the thrown exception can be assigned legally to the argument exception. This permits a subtle refinement. It allows a handler to catch any of several related exception objects with common parentage. Look at this example:

class Grumpy extends Exception {} 
class TooHot   extends Grumpy {} 
class TooTired extends Grumpy {} 
class TooCross extends Grumpy {} 
class TooCold  extends Grumpy {} 

   . 
   : 

      try {
        if ( temp > 40 ) throw (new TooHot() ); 
        if ( sleep < 8 ) throw (new TooTired() ); 
      } 
      catch (Grumpy g) {
           if (g instanceof TooHot) 
              {System.out.println("caught too hot!"); return;} 
           if (g instanceof TooTired) 
              {System.out.println("caught too tired!"); return;} 
      } 
      finally {System.out.println("in the finally clause.");} 
   } 

The catch clauses are checked in the order in which they appear in the program. If there is a match, then the block is executed. The instanceof operator can be used to learn the exact identity of the exception.

If none of the catch clauses match the exception that has been thrown, then the finally clause is executed (if there is one). At this point (no handler for this exception), what happens is the same as if the statement that threw the exception was not nested in a try statement at all. The flow of control abruptly leaves this method, and a premature return is done to the method that called this one. If that call was in the scope of a try statement, then we look for a matching exception again, and so on.

Figure 7-1 shows what happens when an exception is not dealt within the routine where it occurs. The runtime system looks for a “try . . . catch” block further up the call chain, enclosing the method call that brought us here. If the exception propagates all the way to the top of the call stack without finding a matching exception handler, then execution ceases with a message. You can think of this as

Figure 7-1. The result of an exception not dealt within the occurring routine.

Java setting up a default catch block for you around the program entry point that just prints an error message and quits.

There is no overhead to putting some statements in a “try” statement. The only overhead comes when an exception occurs.

Earlier we mentioned that a method must either catch the exceptions that it throws or declare it along with its signature, ^[1] meaning it must announce the exception to the outside world. This is so that anyone who writes a call to that method is alerted to the fact that an exception might come back instead of a normal return.

This allows the programmer calling that method to make the choice between handling the exception or allowing it to propagate further up the call stack. Here is the general form of how a method declares the exceptions that might be propagated out of it:

modifiers_and_returntype name (params)  throws e1, e2, e3  { } 

The names e1 through e3 must be exception or error names (that is, any type that is assignable to the predefined type Throwable). Note that just as a method declaration specifies the return type, it specifies the exception type that can be thrown, rather than an exception object.

An example, taken from the Java I/O system, follows:

 byte readByte() throws IOException; 
short readShort() throws IOException; 
 char readChar() throws IOException; 

The interesting thing to note here is that the routine to read a char can return a char—not the int that is required in C. C requires an int to be returned so that it can pass back any of the possible values for a char, plus an extra value (traditionally –1) to signify that the end of file (EOF) was reached. Some of the Java routines just throw an exception when the EOF is hit. Out-of-band-signaling can be effective in keeping your code well organized. The EOF exception is a subclass of the IOException, so the technique suggested above for handling groups of related exceptions can be applied.

The rules for how much and what must match when one method that throws an exception overrides another work in the obvious way. Namely, if you never do this, you will never obviously be bothered by it. Well, OK, another way to think about it is to consider the exception as an extra parameter that must be assignment-compatible with the exception in the class being overridden.

When you create a new exception by subclassing an existing exception class, you have the chance to associate a message string with it. The message string can be retrieved by a method. Usually, the message string will be some kind of message that helps resolve the problem or suggests an alternative action.

class OutofGas extends Exception {
     OutofGas(String s) {super(s);}  // constructor 
} 

    ... 
// in use, it may look like this 
try {
        if (j<1) throw  new OutofGas("try the reserve tank"); 
      } 
catch ( OutofGas o) {
         System.out.println( o.getMessage() ); 
      } 
   ... 

//At runtime, this message will appear: 
  try the reserve tank 

Another method that is inherited from the superclass Throwable is “printStackTrace().” Invoking this method on an exception will cause the call chain at the point where the exception was thrown (not where it is being handled) to be printed out. For example:

// catching an exception in a calling method 

class test {
   static int myArray[] = {0,1,2,3,4}; 

   public static void main(String[] a) {
      try {
          bob(); 
      } catch (Exception e) {
          System.out.println("caught exception in main()"); 
          e.printStackTrace(); 
      } 
   } 

   static void bob() {

      try {
        myArray[-1] = 4; //obvious out of bounds exception 
      } 
      catch (NullPointerException e) {
         System.out.println("caught a different exception"); 
      } 

   } 
} 

At runtime it will look like this:

caught exception in main() 
java.lang.ArrayIndexOutOfBoundsException: -1 
     at test.bob(test5p.java:19) 
     at test.main(test5p.java:9) 

We will next review the assert statement, then conclude this chapter with a look at our featured class, Integer.