Exception-handling

(info also in Java for Students - ch 16)

Exception: an error, an unusual happening.

Examples

typing a name instead of a number
trying to load a non-existent file
printer out-of-paper

Analogy - company structure


Chart showing who is in charge of who  (NOT inheritance)
Each person is a 'method' which invokes other methods to get work done.

                        MD


           Manager1                Manager2


                                 Chief technician

                                  
                              technician1      technician2

                                 etc...

Possible problems

printer out-of-paper
paper out-of-stock

handled 'locally' or 'thrown' upwards?

Imagine that the person who creatd the company structure (e.g a management consultant) wants to specify - in advance -

the action for each type of error
who takes the action (i.e who handles the error.)

Possibilities for the 'paper' error

Why error-handling is needed

Software is composed of procedures (methods) which call/invoke other methods. This is the case whether we have classes or not.


             a

    b               c


                d       e


                       f       g

e.g a calls b and c
    c calls d and e
    e might be a complex package, split down into f, g internally.
    we may not have it source code - we simply call  e  to make it work.

What happens if we get an error in a low-level method - e.g e ?

Exceptions - the hard way

e.g calling 3 methods in sequence - each can go wrong.



doA();
doB();
doC();

now we add erro-handling, with IF:



doA();
if(doA went wrong)
   handle doA error
else
    doB();
    if(doB went wrong)
        handle doB error
    else
        doC();
        if(doC went wrong)
            handle doC error....

here, the error-handling logic dominates, even though errors don't happen often!

Moving towards java


try {
    doA();
    doB();
    doC();
}
catch ( ){
    handle errors... eg an error message
}

we surround any code that might produce an error with try {...}
Errors in a,b,c are 'thrown' upwards, and the catch {...} takes over.

The detail

When to use exceptions?
for unexpected circumstances.

Example: reading data from a file. Eventually, we are bound to reach the end of the file. This is NOT an exception.

The search for a catcher

Eg. if method a calls method b, then method b calls c.

If c throws an exception, c might catch it locally.
But if there is no appropriate catch in c, Java looks in b, then in a, for a matching catch.

Exception Classes

Exceptions are instances of exception classes. There are lots of them.
They fall into 2 general categories:

checked exceptions - the programmer MUST acknowledge these, otherwise a program will not compile.
unchecked. A programmer might not use try/catch - the program will compile.

3 examples

FileNotFoundException

it is checked, so must catch it locally, or pass it up to the calling method. So either handle it locally:


private void openPayroll(...) {
    try{
        openFile("data.txt"...);  //approx java - possible exception in here
    }
    catch (FileNotFoundException...){
        // maybe display an error message...
    }
}

or state that you will throw it up to the caller:


private void openPayroll(...)
             throws FileNotFoundException{
    openFile("data.txt"...);
}
omitting the throws will produce a compilation error.

NumberFormatException

the docs tell us that parseInt throws it. (we use it when converting a string into an int - e.g the string is from a TextField)
it is unchecked - we can catch or ignore it.
normally best to handle locally (e.g display a mesage asking user to re-input)

ArrayIndexOutOfBounds

e.g:


int a[] = new int[10];  // 0 to 9 
for(int n=0; n <=10; n++){
    a[n]=0;   //error when n is 10
}

this throws an exception
should we catch it and deal with it? - let the program continue? - no.
display eror message and halt? - yes - (the java system will do this if we dont catch)
reason. This is not an error like a number format error - it is a programming error, and needs fixing. Hiding the error will prevent it being fixed. Our message might be of the form:
```
    Drawing package Beta 2
    Array element in 'a' too big in method fred.
    (it is 10, and 9 is the maximum.)
    Contact MSc software immediately!
```

Summary

Some form of error-handling (more than just an IF) is beneficial
Java's is based on the C++ style
It complicated the code a bit
it forces you to deal with certain errors (checked), rather than ignoring them.