Outline of Class 7: Exceptions

Miscellaneous

Administrivia

• No one has signed up for Sunday dinner. Try to let me know by 3pm today if you're interested in coming this week.
• I will not have office hours next Tuesday.
• About class and class participation.
  • "I'll read up on it later" is not a good philosophy.
  • I'd rather not have you nod, but until you start to ask questions when you're confused, I'll keep up with the nodding and other silly feedback options.
  • You need to learn to be able to present and share your designs, algorithms, code, and opinions.
• Ms. Doll and Mr. Wislocki will be presenting next week's case study.
• There are now some examples available for this class, including one that illustrates some things about input.
• I'm somewhat dismayed by the number of you who turned in assignment with a note that "javadoc didn't work." You should have figured that out before you turned in the assignment, read the documentation and gotten help.

Spring Offerings

The department is currently debating whether to offer Artificial Intelligence or Computer Networks during Spring 1998.

• How many would prefer that we offer AI? How many would prefer that we offer networks? How many don't care?
• How many would take AI? How many would take networks? (You don't have to vote in this part.)

About racquetball

• How long did it take you to complete part I of the homework assignment (not counting the time on part II?)
• If player A has a 40% chance of winning a volley in which (s)he serves, and player B has a 60% chance of winning a volley in which (s)he serves (note that the percentages need not equal 100, it's just more convenient in this case), what do you think player A's chances of winning a game are?
• Using your program (or a neighbors, if yours doesn't work yet), determine the chance player A has of winning a game for the previous example.
• Explain your results.

Case study

• This week, Mr. Schnell and Mr. Reasoner will present a fascinating case study on the failed Soviet mars missions, Phobos 1 and 2.
  • No these don't have to be about space missions; they're just documented better than most programs
• Advanced reading can be found at http://cogsci.ucsd.edu/~norman/DNMss/errordesign.html

Exceptions

Reminder about the end of last class

• Last class, we noted that "things go wrong" with programs. What do you, as programmer, do about it?
• These are some options ...
  • Cheer
  • Watch your program crash
  • Cry
  • Prefix code that can fail with a test
  • "Catch" errors when they occur

More about exceptions

• Java supports a concept known as exceptions. Basically, Java admits that things can go wrong, and programmers may want to handle those things.
• Possible problems are called exceptions, presumably because they are exceptions to the rule.
• When something goes wrong, one throws an exception.
• To respond to an exception, one catches it.
• In Java, all exceptions are subclasses of java.lang.Throwable, and most are subclasses of java.lang.Exception.
• The basic structure of Java code for catching with exceptions is

  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.
  }
  

• If you write a method that throws an exception, you must include information about this as part of your method description, as in

  public int MyCoolMethod() throws AlphaBet,Crispies {
    // ...
  }
  

• If your method calls a method that throws an exception, you will (usually) have to either catch the exception or indicate that your method can throw that exception.
• There are a few exceptions that you don't have to explicitly catch or throw. Experience will show you which those are.