Class 34: When Things Go Wrong

Held: Thursday, 1 April 2004

Summary: Today we discuss the problems that may occur in programs and procedures and techniques for indicating and recovering from those problems, particularly Java's exceptions.

Related Pages:

• EBoard.
• EIJ Lab X3.

Assignments:

• Start homework 5.

Notes:

• Happy April Fool's Day!
• Cool convo today.

Overview:

• Problems in Programs.
• Techniques for Handling Errors.
• Exceptions: Java's Primary Error-Handling Technique.
• Dealing with Procedures that Throw Exceptions.
• Optionally-Catchable Exceptions.
• Throwing Exceptions.
• Defining Exceptions.

Problems in Programs

• It's a given that things go wrong in programs.
  • Sometimes, due to mistakes in input or logic, an invalid operation is executed. For example, a program may divide by zero, use an invalid array index, or attempt to read a number as input when the next input character is not a digit.
  • Sometimes, due to problems beyond the programmer's control, the system as a whole cannot respond and requested. (The power might go off; a disk might become inoperative, etc.).
  • Sometimes, the programmer cannot identify errors in advance (for example, a mail client won't necessarily be immediately able to verify that a username or password are incorrect).
  • Sometimes, the people who call a procedure violate that procedures preconditions (perhaps because there is no simple way to check whether or not those preconditions hold).
• What do we do about such problems?
  • Only write correct code. Unfortunately, this doesn't work if there is any communication with the outside world.
  • Let the program crash in such cases. Unfortunately, no one likes ot use programs that crash. (Well, I know that Netscape and Microsoft products are exceptions ....)
• Obviously, programmers need to do more. In considering potential resolutions, we'll look at a few examples.
  • What happens if someone enters "fifty percent" rather than 0.50 in response to a request for the successful serve percentage in a raquetball simulator.
  • Consider the following program for computing an average grade. What happens if the user enters no grades?

        int DONE = -1;
        boolean done = false;
        int count = 0;
        int sum = 0;
        int grade;
        while (!done) {
          out.print("Enter grade: ");
          grade = in.readInt();
          if (grade != DONE) {
            sum = sum + grade;
            count = count + 1;
          }
          else {
            done = true;
          }
        } // while
        out.println("The average grade is " + (sum/count));
    

Handling Errors

• One common technique for dealing with errors is to check for those errors before any operation.
  • We can skip the operation.
  • We can attempt to recover from the error.
• Another common technique is to check for an error after the operation.
  • We can try to recover.
• From the procedure-writer's perspective, we can have our procedures return special values to indicate an error happened, just as Scheme's member returns #f when it can't find the value.
• All three techniques are somewhat dangerous, particularly since there is nothing to ensure that programmers use the technique (that is, they may not check before doing operations and they may not check the return value to see if it signals an error).
• Remember: Java is your nanny!

Exceptions and Exception Handling

• Java uses a variant of the last technique through a concept known as exceptions. The designers of Java decided that there should be a clear standard for handling erroneous or dangerous conditions.
• Java is fairly strict about those exceptions because the designers observed that most programmers
  • assume that things will generally go right;
  • ignore problems when developing developing solutions with the expectation that I'll fix it once I get the 'real' stuff working; and
  • never get back to worrying about errors.
• In Java, possible problems are called exceptions, presumably because they are exceptions to the rule.
• Exceptions are associated with methods. Each method that may lead to errors lists the possible errors (exceptions) that may occur. Any code that uses that method must indicate what to do when the errors occur.
• For example, to say When you try to read an integer you may fail because the user enters a non-number, you might write something like:
• For example, to say When you try to read an integer you may fail because the user enters a non-number, you might write something like:

    /**
     * Read an integer.
     *
     * @exception NumberFormatException
     *   if the user enters something other than an integer
     */
    public int readInt()
      throws NumberFormatException
    // ...
  

• When something goes wrong, a method throws an exception.

Using Methods That Throw Exceptions

• Whenever you call a method that may throw an exception, you need to handle it. You can
  • Deal explicitly with the error.
  • Pass the error on the method that called your method.
• The second is easier, but less useful. To pass an exception on, you need to declare that your method throws the exception.
• For example,

  public static void main(String[] args) 
    throws NumberFormatException
  {
    // ...
    int row = in.readInt();
    // ...
  }
  

• To deal explicitly with exceptions, you need to do a few things.
  • Determine the possible errors that can occur and decide how you want to handle them. (This step requires no coding; instead, it requires careful analysis of the problem.)
  • Note that you understand that errors can occur by placing the potentially exceptional code in a try clause.
  • For each possible exception, list what you want to do to recover from the error in a catch clause.
• In Java,

    try {
      // stuff that may have problems
    }
    catch (ExceptionClass e1) {
      // Handle one type of exception
    }
    catch (AnotherExceptionClass e2) {
      // Handle another type of exception
    }
    finally {
      // Clean up code that is always executed.
    }
  

• For example,

  public static void main(String[] args) {
    // ...
    int row = -1;
    while (row < 0) {
      try {
        row = in.readInt();
      }
      catch (NumerFormatException e) {
        out.println("Not a number");
      }
    } // while
    // ...
  } // main
  

• Java's standard libraries include a number of types of exceptions, including java.io.IOException and java.lang.NumberFormatException.

Optionally-Catchable Exceptions

• What should you do if you want to throw an exception, but you don't care whether the caller catches it or not?
  • Some would argue that this should never happen - all exceptions should be caught.
• You are allowed to throw two things related to exceptions.
  • Errors can not (or should not) be caught. They indicate serious system errors.
  • RuntimeExceptions can be caught, but need not be caught. They seem to be included to accomodate programmers who have not yet bought into (or learned about) Java's exception handling mechanisms.

Throwing Exceptions

• At times, you'll want to throw exceptions from a method because your method has encountered problems.
• In these cases, you'll need to
  • Determine which kind of exception to throw (sometimes an existing kind of exception; sometimes a new kind).
  • Define any new types of exceptions you'll need.
  • Determine an appropriate error message.
  • Create and throw the the exception.
  • Indicate that your method throws
• You can build and throw an exception with
  throw new MyException(message);
• For example, suppose you wanted to ensure that the sender of a message was non-empty. You might write:

    public int readInt()
      throws Exception
    {
      String str = this.readString();
      if (!containsOnlyDigits(str))
        throw new Exception("'" + str + "' is not a number");
      // ...
    } // readInt()
  

Defining Your Own Kinds of Exceptions

• You define your own exception classes with

  public class MyException 
    extends Exception
  {
  } // class MyException
  

• You don't need to include anything in the body due to the wonders of inheritance and polymorphism. This declaration is enough to say that it is possible to create and throw MyException.
• You may also want to create your own parameterized constructor.

  public class MyException
    extends Exception
  {
    public MyException(String msg) {
      super(msg);
    } // MyException(String)
  } // class MyException
  

• This says When someone creates a MyException with a String as a parameter, use that string as the parameter to the constructor of Exception (my superclass).