exceptions part i. old stuff to perform division one must first press a small button on the carriage...
TRANSCRIPT
ExceptionsExceptions
Part I
Old StuffOld Stuff
•To perform division one must first press a small button on the carriage which indicates where the decimal point should be situated in the quotient(bölüm). •Then, the dividend(bölünen) is entered on the big keyboard, and the "ENTER DIVD" button is pressed. This shifts the carriage over to the position indicated for the decimal point, and enters the dividend into the accumulator. •Then, the keyboard is cleared (if the "ADD" key is on, the keyboard clears automatically, however, if it is off, the keyboard must be cleared manually with the "K B CLEAR" key), and the divisor(bölen) entered into the big keyboard. •Then, BOTH divide keys are depressed simultaneously, and the machine begins a process of shifting the carriage to the right to find a point where the divisor can start to be subtracted from the dividend. •Once that point is found, then successive subtractions of the divisor occur until an overdraft (IE: the accumulator goes negative) occurs, and each subtraction is counted in the counter register. •A single addition of the divisor corrects for the overdraft, and then the carriage shifts to the left, and the process repeats until the quotient is left in the counter register, and the remainder is left in the accumulator.
From the manual:
142245 43500 43500 43500 4350 4350 435 435 435 435 435 435 435
300
20
7
327
142245/435 = ?
Slight problemSlight problem
• If division by zero is attempted the calculator just keeps trying to subtract and never stops. Very exciting!
• Okay for a machine with an operator but what about an automatic machine?
• Need to take action upon encountering certain error conditions like “division by zero”
• Architecture modified to detect error conditions and branch to handler code.
• So how do we handle the situation?
Early Approaches to ErrorsEarly Approaches to Errors
• Basic
ONERROR GOTO 100
• Cch = getchar();
/* ch will be set equal to EOF on end of file */
Basic ProblemsBasic Problems
• Programmers never think they will make errors
• Programmers are wrong a lot!
• Want to make code robust(sağlam)
• Want to force users to maintain robustness
• Need a “clean” way of handling problems
Solutions?Solutions?
• Could have methods return a value that tells us whether or not we had an error?– Then can’t return anything else or– Have to return a composite object
• Even with some kind of error code– Does it give us enough information?– Does it give us flexibility– Does it include a way to make sure we check it?
Exceptions--Traditional MethodsExceptions--Traditional Methods
if (someMethod( ) == true) {
if (someOtherMethod( ) == true) {
if (someThirdMethod( ) == true) {
// no errors; do intended actions
}
else {
// handle error caused by someThirdMethod( )
}
}
else {
// handle some error caused by someOtherMethod( )
}
}
else {
// handle some error caused by someMethod( )
}
How would we use?….
Exceptions--Global VariablesExceptions--Global Variables
• Another way to deal with error handling is to have the value of a global variable represent the error.
int iErrorValue = 0;public void someMethod( ) {
// do someMethod’s stuff here// if there is an error, then set iErrorValue = 1
}public void someOtherMethod( ) {
// do someOtherMethod’s stuff here// if there is an error, then set iErrorValue = 2
}public void someThirdMethod( ) {
// do someThirdMethod’s stuff here // if there is an error, then set iErrorValue = 3}
continued
Exceptions--Global VariablesExceptions--Global Variables
public void doIt()
{
someMethod();
someOtherMethod();
someLastMethod();
if (iErrorValue == 1)
...
if (iErrorValue == 2)
...
if (iErrorValue == 3)
...
}
• But: What if the run-time error stopped us from continuing?
• For example: What if someMethod( ) failed in such a way that we cannot go on to someOtherMethod( )?
• To cope, we find ourselves with code that’s nearly as messy as the earlier example which featured multiple nested-ifs:
public void doit( ) {
someMethod( );
if (iErrorValue == 1)
/* Handle Error 1 here */
else {
someOtherMethod( );
if (iErrorValue == 2)
/* handle Error 2 here */
else {
someThirdMethod( );
if (iErrorValue == 3)
/* Handle Error 3 here */
else {
/* do intended actions here */
} // else
} // else
} // else
} // doit
Note: with this techniquewe potentially must wrapthe ENTIRE programin a series of if/else clauses,duplicating code in places.
(Do we prefer robustnessor clarity/maintainability?)
Exceptions--Global VariablesExceptions--Global Variables
Don’t write code like this!
SolutionSolution• Exceptions• Java uses termination model of exception handling:program
control cannot return directly to the throw point – resumption model of exception handling: control would return to
thepoint at which the exception occurred and resume execution.
• Exceptions are thrown– like an NFL referee throws a penalty flag
• Exceptions can be thrown by Java (Today)• Exceptions can be thrown by you! (Next Time)
What you need to knowWhat you need to know
• Today– What happens when an exception is thrown– What are your choices for handling exceptions– The different kinds of exceptions
• Next Time– How to write your own exceptions– Details of the classes– Why and when you should use exceptions– Some typical scenarios
Two Main IdeasTwo Main Ideas
Handling Exceptions thrown by someone else
Throwing Exceptions &writing your own Exceptions
Today
Next Time
What happens when an exception is What happens when an exception is thrown?thrown?
• An exception object is created (on the heap)• The current “context” is halted/aborted• Execution starts in some error handling code
– Can be in current method– Can be external to current method
• The error handling code has access to the exception object which can be used to– Access a String message contained in the exception– Determine what type of exception was thrown– Print a stack trace– Other cool stuff (like rethrow the exception, increment a counter, etc.)
What are your choices for What are your choices for handling exceptionshandling exceptions
• Handle in current methodtry
{
/* Code that might throw an exception */
}
catch (ExceptionType <ident>)
{
/* Code that handles exception */
}
• Handle outside current methodvoid someMethod() throws Exception { }
void someMethod throws AnotherException { }
More detailson this later!
More detailson this later!
The different kinds of exceptionsThe different kinds of exceptions
• Error– For the big guys
• Exception– The “standard” exception– Java enforces handling– An unusual condition
• RuntimeException– e.g. classCast Exception– Can indicate using a class improperly– No special handling
15.4 Java Exception Hierarchy15.4 Java Exception Hierarchy
• Superclass Throwable– Subclass Exception
• Exceptional situations
• Should be caught by program
– Subclass Error• Typically not caught by program
• Checked exceptions– Catch or declare
• Unchecked exceptions
Inheritance hierarchy for class Inheritance hierarchy for class ThrowableThrowable
Throwable
Exception Error
AWTError ThreadDeathIOExceptionRuntimeException OutOfMemoryError
Details of the classesDetails of the classesObject
Error Exception
RuntimeException
Throwable
others...
getMessage
printStackTrace
toString
IOException
15.8 15.8 printStackTraceprintStackTrace, , getStackTracegetStackTrace and and getMessagegetMessage
• Throwable class– Method printStackTrace
• Prints method call stack
– Method getStackTrace • Obtains stack-trace information
– Method getMessage• Returns descriptive string
Nitty GrittyNitty Gritty
• A method which throws an exception must explicitly “announce” this fact (compiler enforced) in the method header throw clausepublic void someMethod() throws SomeException
UNLESS• The exception is a RuntimeException (or a child of
RuntimeException)
OR• The exception is handled inside the method
Here’s the ideaHere’s the idea
• If you as a developer write a class with a method that throws an exception then Java forces all users of the class to deal with it.
• This is unlike earlier programming languages where there was no way to insure that programmers properly handled error conditions.
• Again we try to deal with problems at compile time as opposed to runtime
But what about RuntimeExceptions?But what about RuntimeExceptions?
• Certain types of exceptions can occur in almost every method and including code for these conditions would be burdensome
• Runtime Exception Examples: – ArithmeticException– ClassCastException– EmptyStackException– IllegalArgumentException– IndexOutOfBoundsException – UnsupportedOperationException – NegativeArraySizeException– NoSuchElementException– NullPointerException
So no special notemust be made in method headers.
So no special notemust be made in method headers.
And it doesn’t have to be handled. Program can be
allowed to terminate.
And it doesn’t have to be handled. Program can be
allowed to terminate.
Handle Them Yourself!Handle Them Yourself!
• One or more statements that might throw an exception are placed in a try block
• The try block is followed by one or more catch blocks
catch(IOException ioe)
{/* Code to handle IOException here e.g.:*/
System.out.println(ioe.getMessage());
}
catch(Exception e)
{
/* Code to handle other exceptions here */
}
Put the subclasses before the classesPut the subclasses before the classes
15.6 15.6 finallyfinally Clause Clause
• Resource leak– Caused when resources are not released by a program
• The finally block– Appears after catch blocks– Always executes– Use to release resources
FinallyFinally
• In certain cases (no matter what) it is desirable to have some code that will be executed after the try block. (Like closing a file or a network connection).
• This means whether or not exceptions were encountered.• The solution is the finally block
try {}
catch(Ex1 e) {}
catch(Ex2 e) {}
finally
{
/* Code that will execute! */
}
Don’t pack upyour books yet!
ScenarioScenario
• You are trying to use a method that throws an exception. The compiler is complaining. It’s late.
You are trying to use a method that throws an You are trying to use a method that throws an exception. The compiler is complaining. It’s late.exception. The compiler is complaining. It’s late.
class SomeClass {...public void someMethod(...) {
...BufferedReader stdin = new BufferedReader(
new InputStreamReader(System.in));inbuf = stdin.readLine();...
}...
}C:>javac SomeClass.javaSomeClass:299: Exception java.io.IOException must be
caught, or it must be declared in the throws clause of this method.
inbuf = stdin.readLine(); ^1 error
Check the API...Check the API...
readLine
public String readLine()
throws IOException
Read a line of text. A line is considered to be terminated by any one of a line feed ('\n'), a carriage return ('\r'), or a carriage return followed immediately by a linefeed.
Returns:
A String containing the contents of the line, not including any line-
termination characters, or null if the end of the stream has been reached
Throws:
IOException - If an I/O error occurs
You are trying to use a method that throws an You are trying to use a method that throws an exception. The compiler is complaining. It’s late.exception. The compiler is complaining. It’s late.
BufferedReader stdin = new BufferedReader(
new InputStreamReader(System.in));
try
{
inbuf = stdin.readLine();
}
catch (IOException ioe)
{
System.out.println("Oh, darn!");
} Java requires you to somehow handle the exception. It doesn’t require you to do anything smart.
You are trying to use a method that throws an You are trying to use a method that throws an exception. The compiler is complaining. It’s late.exception. The compiler is complaining. It’s late.
class SomeClass {
...
public void someMethod(...) throws IOException {
...
BufferedReader stdin = new BufferedReader(
new InputStreamReader(System.in));
inbuf = stdin.readLine();
...
}
...
}
Or you could just add throws IOException to the method header
Or you could just add throws IOException to the method header
You are trying to use a method that throws an You are trying to use a method that throws an exception. The compiler is complaining. It’s late.exception. The compiler is complaining. It’s late.
class SomeClass {
...
public void someMethod(...) throws IOException {
...
BufferedReader stdin = new BufferedReader(
new InputStreamReader(System.in));
inbuf = stdin.readLine();
...
}
...
// Someplace else
someReference.someMethod() // Now this line is a problem!!!
}
Of course, if you use thistechnique you still needto deal with the problem!
Of course, if you use thistechnique you still needto deal with the problem!
• Print an error message
• Log the exception
• Retry the method(maybe with default parameters)
• Restore the system to some previouslyknown "good" state.
• Set the system to some "safe" state.
•Let exception propagate to whoever called the method in which the exception arose
• Catch it and ignore it
“Catch it and ignore it” is generally bad: If the error was serious enough
to throw an exception, it should be dealt with, not ignored.
When Catching Exceptions you can . . .When Catching Exceptions you can . . .OOA/OOD/OOP“Who” knowsenough to handlethe exception?
local?
high-level?
Questions?Questions?