Transcript throwing an exception

Exception
Handling
What Is an Exception?
•
•
•
•
•
•
•
•
The term exception is shorthand for the phrase "exceptional event.“
Definition: An exception is an event, which occurs during the execution
of a program, that disrupts the normal flow of the program's instructions.
When an error occurs within a method, the method creates an object and
hands it off to the runtime system.
The object, called an exception object, contains information about the
error, including its type and the state of the program when the error
occurred.
Creating an exception object and handing it to the runtime system is
called throwing an exception.
After a method throws an exception, the runtime system attempts to find
something to handle it.
The set of possible "somethings" to handle the exception is the ordered list
of methods that had been called to get to the method where the error
occurred.
The list of methods is known as the call stack (see the next figure).
• Exceptions are actual objects.
• They are instances of classes that
are inherited from the class
Throwable.
• An instance of a Throwable class is
created when an exception is thrown.
Throwable
Exception
Error
IOException
ClassNotFoundException
AWTException
EOFException
FileNotFoundException
MalFormedURLException
RuntimeException
ArrayIndexOutofBounds
SocketException
• Throwable class methods:
– getMessage() gets a string that details
information about the exception.
– toString()
converts the object to a
string that can be displayed onscreen.
– printStackTrace()
displays the
hierarchy of method calls that lead to
the exception.
Catching java exception
• Protect the code in try block that
might throw an exception.
• Test for and deal with exception
inside a catch block.
• The catch block should immediately
follow the try block.
try {…………..}
catch(IOException e){………}
• Throwable has two subclasses Error
and Exception class.
• Instance of Error class are internal
errors in JVM.
• These errors are rare and are usually
fatal.
• Exceptions are arranged in a
hierarchy like other classes.
• Most of the exception classes are
part of the java.lang package.
• Many other packages define other
exceptions.
• Example
• Example
• Example
• Example
• Example
1
2
3
4
5
• A subclass must come before its
superclass in a series of catch
statements.
• If not, unreachable code will be
created and a compile-time error will
result.
• Example
Finally clause
• Let there are some actions in the
code that must be performed no
matter what happens i.e. whether an
exception is thrown or not.
• This can be done by placing the code
inside and outside the catch block
But that duplicate the same code.
• Instead we can use finally block with
try and catch block.
try
{
……..}
catch(IOException e)
{
….}
finally
{
…….}
• It is used to execute cleanup code after a
return, a break, or continue inside loop.
• Example
• Note: If the JVM exits while the try or
catch code is being executed, then the
finally block will not execute.
• Likewise, if the thread executing the try or
catch code is interrupted or killed, the
finally block will not execute even though
the application as a whole continues.
The throws Clause
• A method may throw an exception, for this a
throws clause is used in method definition.
• It indicates that some code in the method may
throw an exception.
• A throws clause lists the types of exceptions that
a method might throw.
• This is necessary for all exceptions except
Error and RuntimeException or any of their
subclasses.
Public void methodName(plist)throws
ExceptionName1, ExceptionName2
{……..
}
User defined Exceptions
• To create and throw user-defined
exception, first a class must be
defined for the exception, usually
this class is derived from Java
Exception class.
public class MyException extends
Exception
{
public MyException(String msg)
{
super(msg);
}
}
• super(msg) passes the string upwards to
MyException super class Exception.
• The Exception class in turn passes the
string upwards to the Throwable class
where it is stored as a data member of the
class.
• This string is the message detail that the
class returns, when its getMessage() is
called.
• Example
• The Three Kinds of Exceptions
• The first kind of exception is the checked exception.
• These are exceptional conditions that a well-written application
should anticipate and recover from.
• For example, suppose an application prompts a user for an input
file name, then opens the file by passing the name to the
constructor for java.io.FileReader.
• Normally, the user provides the name of an existing, readable file,
so the construction of the FileReader object succeeds, and the
execution of the application proceeds normally.
• But sometimes the user supplies the name of a nonexistent file,
and the constructor throws java.io.FileNotFoundException.
• A well-written program will catch this exception and notify the
user of the mistake, possibly prompting for a corrected file name.
• All exceptions are checked exceptions, except for those indicated
by Error, RuntimeException, and their subclasses.
• The second kind of exception is the error.
• These are exceptional conditions that are external to the
application, and that the application usually cannot
anticipate or recover from.
• For example, suppose that an application successfully
opens a file for input, but is unable to read the file because
of a hardware or system malfunction.
• The unsuccessful read will throw java.io.IOError.
• An application might choose to catch this exception, in
order to notify the user of the problem.
• Errors are those exceptions indicated by Error and its
subclasses.
• The third kind of exception is the runtime exception.
• These are exceptional conditions that are internal to the
application, and that the application usually cannot anticipate or
recover from.
• These usually indicate programming bugs, such as logic errors or
improper use of an API.
• For example, consider the application described previously that
passes a file name to the constructor for FileReader.
• If a logic error causes a null to be passed to the constructor, the
constructor will throw NullPointerException.
• The application can catch this exception, but it probably makes
more sense to eliminate the bug that caused the exception to
occur.
• Runtime exceptions are those indicated by RuntimeException and
its subclasses.
• Errors and runtime exceptions are collectively known as
unchecked exceptions.
How to Throw Exceptions
• Example
• Example
Chained Exceptions
•
An application often responds to an exception by throwing another exception.
•
In effect, the first exception causes the second exception. It can be very helpful to
know when one exception causes another.
•
Chained Exceptions help the programmer do this.
•
The following are the methods and constructors in Throwable that support chained
exceptions.
Throwable getCause()
Throwable initCause(Throwable)
Throwable(String, Throwable)
Throwable(Throwable)
•
•
•
The Throwable argument to initCause and the Throwable constructors is the
exception that caused the current exception.
getCause returns the exception that caused the current exception, and initCause sets
the current exception's cause.
The following example shows how to use a chained exception.
Advantages of Exceptions
• Advantage 1: Separating ErrorHandling Code from "Regular"
Code
readFile {
try {
open the file;
determine its size;
allocate that much memory;
read the file into memory;
close the file; }
catch (fileOpenFailed) {
doSomething; }
catch (sizeDeterminationFailed) {
doSomething; }
catch (memoryAllocationFailed) {
doSomething; }
catch (readFailed) {
doSomething; }
catch (fileCloseFailed) {
doSomething; } }
Advantage 2: Propagating
Errors Up the Call Stack
• A second advantage of exceptions is the ability to
propagate error reporting up the call stack of methods.
• Suppose that the readFile method is the fourth method in a
series of nested method calls made by the main program:
• method1 calls method2, which calls method3, which finally
calls readFile.
• method1 { call method2; }
• method2 { call method3; }
• method3 { call readFile; }
• Suppose also that method1 is the only method interested in
the errors that might occur within readFile.
• Traditional error-notification techniques force method2 and
method3 to propagate the error codes returned by readFile
up the call stack until the error codes finally reach
method1—the only method that is interested in them.
• method1 {
errorCodeType error;
error = call method2;
if (error) doErrorProcessing;
else proceed; }
errorCodeType method2 {
errorCodeType error;
error = call method3;
if (error) return error;
else proceed; }
errorCodeType method3 {
errorCodeType error;
error = call readFile;
if (error) return error;
else proceed; }
Recall that the Java runtime environment searches backward
through the call stack to find any methods that are interested in
handling a particular exception.
A method can duck any exceptions thrown within it, thereby
allowing a method farther up the call stack to catch it.
Hence, only the methods that care about errors have to worry
about detecting errors.
method1 {
try {
call method2; }
catch (exception e) { doErrorProcessing; } }
method2 throws exception { call method3; }
method3 throws exception { call readFile; }
However, as the pseudocode shows, ducking an exception requires
some effort on the part of the middleman methods. Any checked
exceptions that can be thrown within a method must be specified
in its throws clause.
Advantage 3: Grouping and
Differentiating Error Types
• Because all exceptions thrown within a program are
objects, the grouping or categorizing of exceptions is a
natural outcome of the class hierarchy.
• An example of a group of related exception classes in the
Java platform are those defined in java.io — IOException
and its descendants.
• IOException is the most general and represents any type of
error that can occur when performing I/O.
• Its descendants represent more specific errors.
• For example, FileNotFoundException means that a file could
not be located on disk.
• A method can write specific handlers that can handle a very
specific exception.
• The FileNotFoundException class has no descendants, so
the following handler can handle only one type of
exception.
Built-in Exceptions
• Java.lang has many exception
classes.
• Many of them are subclasses of
RunTimeException.
• As java.lang, RuntimeException is
automatically available.
• So they need not to be included in
any methods throws list.
Unchecked Exception
• Not included in throws list.
• ArithmeticException
• ArrayIndexOutOfBoundsException
• ArrayStoreException
• ClassCastException
• IllegalArgumentException
• NullPointerException
• NumberFormatException
Checked Exception
• ClassNotFoundException
• CloneNotSupportedException
• IllegalAccessException
• InstantiationException
• InterruptedException
• NoSuchFieldException
• NoSuchMethodException