Copyright © 2000, 2001 by Daniel Berleant

 

Exceptions

·       “Exception” is short for “exceptional event”

·       . . . or an event which is unusual and non-standard

·       . . . errors are a typical exception =>FIND SIMILAR

·       . . . end of file exception might/might not be an error

·       . . . exception handling is often error handling

 

 

Two types of exceptions

·       Run time exceptions: problems detected within the “java” program =>FIND SIMILAR

-        Example 1: array out of bounds exceptions

-        Example 2: divide by zero exceptions

-        . . . these do not occur at the disk (e.g. missing file)

-        . . . or anywhere else “outside” the Java system =>FIND SIMILAR

-        . . . they occur inside the program we call java

-        . . . (e.g. when you run     java hello    )

-        . . . yes, even divide-by-zero is detected within java =>FIND SIMILAR

-        . . . you may try{…}catch{…} runtime exceptions

§       but you don’t have to

·       Checked exceptions: occur outside    java

-        They occur in code outside the program java =>FIND SIMILAR

-        These are (in a sense) not the programmer’s fault

-        Example 1: disk unreadable (e.g. bad disk)

-        Example 2: disk unreadable (e.g. not in drive)

-        Example 3: disk unreadable (e.g. write protected) =>FIND SIMILAR

-        Examples 4 etc.: anything you must deal with

§       as with a try{…}catch(…){…}

 

 

How Java deals with exceptions

·       Run time exceptions:

-        you can catch them

-        you don’t have to catch them =>FIND SIMILAR

-        don’t catch them program terminates

·       Checked exceptions:

-        Java is built to check for them

-        . . . but Java’s own code can’t do it

-        . . . the operating system typically notices these =>FIND SIMILAR

-        . . . if they happen, they must be caught

-        the check is during compilation

-        Java checks: were they catch’ed  or  try’ed?

-        Yes  Java keeps cool =>FIND SIMILAR

-        No    Java gets upset:

§       temp.java:4: Exception  java.io.IOException must be caught, or it must be declared in the throws clause of this method.

System.in.read();

 

 

catch’ing and trying-ing Exceptions =>FIND SIMILAR

·       Exceptions that are checked can be in a

try{…}catch(…){…}

·       For previous example, it could be

try{…}catch(IOException E){…}

·       Or, it could be

try{…}catch(Exception E){…}

·       Or, in principle it could be =>FIND SIMILAR

try{…}catch(Throwable E){…}

but not

try{…}catch(int E){…}

   and not

try{…}catch(Object E){…}

·       You probably wouldn’t actually want to use Throwable, but if you did, you could WHY?

-        Because of the inheritance hierarchy - see Figure 77 p. 257 (spring 2001), or http://java.sun.com/docs/books/tutorial/essential/exceptions/throwable.html =>FIND SIMILAR

-        In more detail, from

-        http://java.sun.com/products/jdk/1.2/docs/api/java/io/package-tree.html -

=>FIND SIMILAR

-        More, these from

-        http://java.sun.com/products/jdk/1.2/docs/api/java/net/package-tree.html -

=>FIND SIMILAR

-        You could also define your own exception classes:

-        public class trafficLightException extends throwable{

. . .

 

·       Why not catch an Object?

-        …because catchableness is a property only of Throwable and descendants =>FIND SIMILAR

·       Note: you can define your own derived exception class and try…catch it

-        try{…}catch(MyExceptionClass M){…}

-        but only if what you try{…} throws a MyExceptionClass object

-        (We haven’t seen how to throw yet =>FIND SIMILAR

but we’ve catch’ed things that Java throws)

 

 

try…catch More Details

·       try…catch is a bit like the C switch statement

·       Your try can contain several checked statements

·       . . . the catch distinguishes among them =>FIND SIMILAR

·       Example:

-        try{d=new DatagramSocket(mach3456.ee.iastate.edu);

    u=new URL(“http://howdy.htm”);

}

catch(malformedURLException M){

    …deal with read() problems

}

catch(UnknownHostException U){

    …deal with unknown machines

}

//...following is optional...

finally{

    myFile.close();

}

·       Yes, you can also have a finally clause if you want =>FIND SIMILAR

-        Otherwise, an undesirable situation occurs:

-        If the try’ed thing does work:

§       you have to close in the try{…} clause

-        If the try’ed thing doesn’t work: =>FIND SIMILAR

§       you have to close() in the catch(…){…} clause(s)

-        Better to do it in one place

-        finally{...} is optional

-         if present, it runs after either try{...} or catch(...){...} =>FIND SIMILAR

 

You can “throw” outside the method instead of catch’ing

·       Why?

·       If your class is to be used by other programmers,

-        Better to throw so they can try...catch it per their requirements =>FIND SIMILAR

-        Example: what to do if there is a disk problem?

§       Better to let the other programmer decide. . .

 

How? With  throw

·       You can handle an exception “later” =>FIND SIMILAR

·       . . . that is, in one of the calling methods

·       . . . any method in the call stack will work

·       Your method looks like:

-        public void myMethod() throws =>FIND SIMILAR

                   IOException,

                   MalformedURLException

{...}

·       Now, myMethod() can declare URLs and do IO

-         with no try...catch

·       Instead, somewhere there is:

YourMethod() throws IOException{

   try{myMethod();

   catch(UnknownHostException U){

         ...

        }

   }

·       . . . and even earlier some method needs to try…catch the IOException =>FIND SIMILAR

 

Time: 45 min. including questions

=>FIND SIMILAR