Lecture 37, CS 302-7 and 8, April 23

  1. Various things
    1. Program 2

                                                               i.     Grades online

    1. Program 4

                                                               i.     Coming soon – stay tuned

  1. Review:
    1. String parsing

                                                               i.     String methods

                                                             ii.     Scanner

                                                            iii.     <String>.split(<String delimiter>);

    1. Exceptions

                                                               i.     Signal that something went wrong

                                                             ii.     Some examples:

1.    ArrayOutOfBoundsException

2.    NullPointerException

3.    ArithmeticException

4.    FileNotFoundException

  1. A more general view of exception handling
    1. Detection

                                                               i.     Recognizing that an exception has occurred.  For instance, unable to open the filename specified.

    1. Handling

                                                               i.     Doing something productive with that exception

                                                             ii.     What exactly this means will depend on the context of the exception

1.    Different exceptions/situations require different handling.

    1. Exceptions are Classes that we create objects from.  There is a hierarchy of exceptions that we will discuss in a week or two.  Some are more specific versions of others while some, such as Exception, are very general.
  1. Detecting
    1. When we detect an Exception – Throw it!

if(/*Something bad happens*/) {

throw new <Type of Exception>();

}

    1. throw vs throws
    2. This doesn’t handle the exception – just throws it
    3. We’ll see that exceptions are objects. That’s why the syntax looks familiar. We can call constructors, methods, etc on them.

if(/*Something bad happens*/) {

      throw new <Type of Exception>(“Abort! Something bad happened!”);

}

  1. Step two - handling
    1. When an exception is thrown, execution continues with the appropriate exception handler.  This may or may not be in the same method/class.  It will go in order down the call stack until a handler is found.
    2. If an exception is unhandled, the program will end, and display an error message.
    3. We handle exceptions via try/catch blocks.

                                                               i.     try – we’ll try to execute some code.  It might throw an exception before it is completed.

                                                             ii.     catch – we’ll catch a specific type of exception that might occur in the code, and handle it accordingly.

    1. Syntax:

try {

                        //Code that might cause exception

}

catch(<Type of exception> <object name>)

{

            //Do something, such as:

            //<objectName>.printStackTrace();

}

    1. Each ‘catch’ block can handle a certain type of exception, such as FileNotFoundException or IOException.
  1. Different types of things that can go wrong.
    1. Errors

                                                               i.     These are issues related to our computer or something else, such as running out of memory.  We won’t worry about these.

    1. Unchecked Exceptions

                                                               i.     These are exceptions that are ‘preventable’.  They are the result of buggy code.

                                                             ii.     For instance: ArrayIndexOutOfBoundsException, NullPointerException

                                                            iii.     Java does not require us to handle these

    1. Checked Exceptions

                                                               i.     These are exceptions that we can’t predict

                                                             ii.     For instance: FileNotFoundException, IOException

                                                            iii.     Java requires us to handle these

                                                           iv.     All checked exceptions must be handled somehow

1.    If we say that the method throws that exception, it will be passed up the call stack to the method that called this method.

2.    If we handle the exception with a try/catch block, we do not keep searching up the call stack – the JVM is satisfied.

3.    If there is an exception that can be thrown by the code in the try block, but it is not handled in a catch block, we still must acknowledge that the method throws that exception – we will then search up the call stack hierarchy.

  1. Exception philosophy
    1. In general – we should only attempt to handle an exception when we know the proper thing to do with it.
    2. Don’t be hasty to deal with it unless you have to – good programmers are lazy
  2. Catching exceptions
    1. You can catch unchecked exceptions, such as array index out of bounds or input mismatch exception
    2. Catch locally – in same method

                                                               i.     UncheckedException.java, CheckedException.java

1.    ArithmeticException and InputMismatchException

2.    FileNotFoundException

3.    OutOfMemoryError

a.    Can’t catch…

4.    What are the differences between the three?

    1. Catch remotely – in method from call stack

                                                               i.     Must throw it in callee

                                                             ii.     Then, catch it in caller

  1. Using javaDoc
    1. When we are using methods/constructors, it’s helpful to know what exceptions they can throw, and whether those are checked or unchecked.
    2. The javadoc tells us this.
  2. Generic Exceptions – Exception e
  3. Homework – Read 8.4-8.5