CSC153 2004S, Class 34: Exceptions (When Things Go Wrong)

Admin:
* New homework!  Yay!
* Cool convo!  Yay!
* Exam today!  Yay!

Overview:
* What kinds of things go wrong with programs?
* What can we as programmers do to help deal with these errors?
* What would your nanny say?
* Java's solution: Exceptions
* Dealing with exceptional methods
* Creating exceptional methods
* Creating exceptions

Exam 3: Java
* Write your name on the top of the page
* Side one (question one): Sketch the design of a "point in the plane" class.
* Side two (question two): List five ways in which "Java is your nanny"
* You have until 10:30
* NO COMPUTERS ERIK
* April fools

What mistakes can programmers make
* Programmer confusion of variables
* Syntax
* Write the wrong algorithm
* More than we can list in 24 hours

What kinds of things typically go wrong in (syntactically and semantically correct) programs?
* The idiot user can type the wrong thing at the wrong time:
	Please enter a number
	> Two
* Your memory can corrupt your values / The campus power grid may give up again / Dangerous chemicals can be found in the science division and folks can overreact severely
* The file system can fill, files can change, files can disappear
* Sometimes computations are inadvertently incorrect (e.g., division by 0, overflow)

Anticipate the error in advance of calling the potentially failing code
* Before you attempt to read from a file, you make sure that you can still read from the file
* Before you attempt to multiply two numbers, you make sure the result will not be too large

What do you do if you observe that what you're going to do is about to fail?
* Report an error by returning a special value
* Figure out a way to recover from the error
* Assume the problem never happens, since other people should be checking, too

Return a special "Whoops, that was erroneous" value
;;; Procedure:
;;;   member
;;; Parameter:
;;;   val, a value
;;;   lst, a list of the form (v1 v2 .... vn)
;;; Purpose:
;;;   Determine whether val is a member of lst
;;; Produces:
;;;   result, a Scheme value
;;; Preconditions:
;;;  
;;; Postconditions:
;;;   If val does not appear in lst, result is #f
;;;   If val equals vi for some i, returns the list (vi ... vn)

(let ((result (member foo bar)))
  (if result
      (...)
      (error "Sorry, foo does not appear in bar")))

Two strategies:
* Check in advance
* Check return value

Example: printf can fail
  Does anyone ever check the result of printf?
  Rarely

"I'll put in error checking when I have time.  For now, I'll just assume it works okay."
* No one ever has time to go back and fix it
* Avoids the problem of "What am I going to do when things go wrong?"
* Smart programmers put them in when they go (it's hard to figure out where error messages go)

Just saying "I had a problem" is not very informative.

Java requires you to deal with the errors of potentially erroneous procedures
Java allows you to distinguish things that go wrong

Three key issues:
* Dealing with procedures that may have problems
* Informing others that your procedures may have problems
* Describing problems

Methods in Java can "throw exceptions" (report an error)
* Exceptions are objects