Class 09: When Things Go Wrong

Held Monday, February 8

Summary

• Design: How to handle and check errors
• Exceptions: Java's primary error-handling mechanism
• ``Primitive'' classes: Integer, Double and friends.
• Lab X3: Input, output, files, and exceptions

Contents

Handouts

• Documentation for
  • java.lang.Integer
  • java.lang.Double
  • java.io.BufferedReader

Notes

• I'll be returning assignment 2 today.
  • I've updated the answer key.
  • Many of you didn't seem to try to think about the whys or `` what will happen if ...?'' questions (or at least didn't reveal so in your answers). Perhaps it was too obvious.
  • This will be the last lab-based homework. (You'll still do labs in class, but ...)
  • Since few of you went beyond the problems as stated, most of you got B's. Those of you who seemed to be going through the motions may have gotten lower grades (even if you were going through the motions because you have such good understanding).
  • Some of you didn't quite do what was stated. As Clif says ``Sometimes lab instructions are very important. In chemistry, it makes a difference whether you add water to acid or acid to water''.
  • There seems to be some confusion about the difference between a constructor and a method. We'll discuss this.
• So, has anyone figured out a better way to compute 1 + 2 + ... + n without using loops?
  • There's a great story about (Gauss, I think), who was asked to add the numbers from 1 to 1000 because he was annoying the teacher, and he came back with an answer in less than a minute.
• I've made some fairly substantial changes to the lab in thinking about today's class. Please make sure to refer to the online version.
• Once again, I've made some slight changes to the syllabus to give you the option to do more fun things. In this case, we're going to study Java's abstract windowing toolkit this Wednesday, and delay our study of arrays until next week.
  • I'll have the labs ready in time for Tuesday's class, so you can read them in time for Wednesday.
• I'm working hard on the textbook. Expect some chapters or sections in the next few days (there will be a slight delay as they go through the service bureau).
• You should scan lab O2: Interfaces and lab O3: Inheritance before tomorrow's class. However, we will not be doing these labs, simply reflecting on the content.
• Our own Eric Otoo is giving a presentation this evening on ``Names''. Since we've been talking about naming in Java, I'm sure you'll find it applicable. (It's particularly admirable that he's attempting a presentation this afternoon, given that he's spent the weekend on the legendary modeling context and is probably running on very little sleep.)

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. This may be division by 0, an out-of-bounds array reference, an incorrect input, or a number of other things.
  • Sometimes, due to problems beyond the programmer's control, the system as a whole cannot respond and requested.
• 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.
  • Try to predict the cases, and prefix any statement that may have problems with a test and recovery.
  • Require potential erroneous methods to set a flag if they have errors, and check that flag afterwards. For example, we can use the hadError method of SimpleInput to check whether there was an error in input.
  • Wait for the system to tell us about the problem, and react to that notification.

Exceptions and Exception Handling

• Java supports a concept known as exceptions. Basically, Java admits that things can go wrong, and programmers should handle those things.
• 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"
  • 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.
• When something goes wrong, a method throws an exception.
• Whenever you call a method that may throw an exception, you need to handle it. You can
  • Deal 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, as in

    public int MyCoolMethod() 
      throws IOException, NumberFormatException {
      ...
    } // MyCoolMethod()
  

• To deal 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 requires no coding; it is 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.
    }
  

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

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 create and throw an exception with
  throw new MyException(message);
• You indicate that your method may throw an exception with a throws clause, as in

    public static void teach()
      throws ClassOverException {
      ...
    } // teach()
  

• For now, you can just use the generic Exception class. Later, we'll see how to define our own exceptions.

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.
  • RuntimeExceptions can be caught, but need not be caught.

Input and Output

• How do exceptions affect you? It turns out that you need to understand exceptions in order to use many of Java's built-in classes.
• For example, there are many times in which you need to ``parse'' a string to find a corresponding value (e.g., an integer).
  • The constructor for the Integer class can build an Integer object from a string.
  • The intValue method extracts the integer value.
• What should happen when we try to create an integer from something else? It turns out that Java throws an exception.
  • We may then want to (or be required to) catch that exception.
• You will explore this problem in more depth in the lab.

Java's Primitive Classes

• At times, you will find a need to use primitive types in places in which Java only permits you to use objects.
• In addition, there are a number of standard functions that you might want to do with the primitive types.
• To support such instances, Java provides object (class) equivalents of the primitive types. These include java.lang.Integer, java.lang.Double, and many many more.
• What good do they do you?
  • You can get the minimum and maximum allowable integer values with Integer.MIN_VALUE and Integer.MAX_VALUE. (The same is true for other types.)
  • You can convert strings to these objects (``parsing'' the value) by passing the string to the class constructor.
  • You can extract the corresonding integer with intValue (and related things).
  • You can convert between bases and also print numbers in different forms. (We'll return to this later in the semester.)
• Unfortunately, some of these methods can throw exceptions, and you must be prepared to handle them.

Lab

Do X3.5 and X3.6.

History

• Created Monday, January 11, 1999.
• Added short summary on Friday, January 22, 1999.
• Added most of the outline on Friday, February 5, 1999. Much of this was based on outline 10 from last year's class.
• Added some more notes on Sunday, February 7, 1999.