Handling exceptions is a very easy task in Java and can be utilized to the best.
When an exception occurs the program must do either of the two things:
Return to safe state and allow the user to execute other commands.
Allow the user to save all his work and terminate the program gracefully.
In Java all classes that handle exceptions are derived from throwable.
Also one can create one’s own exception class by extending either of the exception classes available.
Following is a figure depicting the hierarchy of Exception classes in Java:
Exception Class Hierarchy
As is clearly visible from the diagram, the hierarchy of errors splits into Errors and Exception.
Error Exception The Error hierarchy describes the internal errors and the errors that occur due to resource exhaustion in the Java runtime system. The Exception hierarchy describes the errors happening due violation of some rule of Java language or due to violation of some constraints of Java Runtime Environment.
Error hierarchy describes the internal errors and resource exhaustion inside the Java runtime system.
One should not throw an object of this type.
One cannot do much but to inform user and try terminate the program gracefully when such an internal errors occur which is a case that happens very rarely.
Exception hierarchy is the one that we focus on mostly when programming in java.
Exceptions are of two types, checked exception and unchecked exception:
| Checked exception | Unchecked Exception |
| Checked exceptions are instances of Exception classes or its sub-classes (excluding RuntimeException and its subclasses). The compiler expects all checked exceptions to be appropriately handled. Checked exception must be declared in throws clause of method throwing exception. The calling method must take care of these exceptions by either catching or declaring them in its throws clause. These Exceptions are not derived from the Runtime class hierarchy and include exceptions such as: Trying to read after the end of file. Opening a malformed URL. Accessing a non existing class. | Unchecked Exceptions are instances of RuntimeException class or one of its sub classes. We don’t need to declare unchecked exception in the throws clause of the throwing method. Also, the calling method doesn’t have to handle them. Mostly, unchecked exceptions throw only problems arising in JVM These Exceptions are derived from Runtime class and include exceptions such as: Illegal Typecasting. Array index out of bound. Null Pointer Exception. |
Difference between Checked and Unchecked exceptions.
In Java we can also declare our own Exception class if the standard inbuilt classes do not suit our needs.
All we need to do is just extend any of the base class of Exception under which our class can best fall and describe our own exception handling mechanism in that class’ method.
Following is an example of a simple Exception class which extends IOException class.
import java.exception.*;
import java.io.*;
//the list of other files to be imported goes here.
public class MyException extends IOException {
public MyException (){
// the codes go here.
}
public MyException( String msg){
super (msg);
//other codes come here.
}
}
In Java Exception handling is done mostly using either or all of the following:
Throws keyword.
Throw keyword.
Try-catch-finally block.
When we need to throw an exception from a function, we do it using the throw command, and declare that a function throws such an exception which the user of the function should catch using the throws command.
public void somefunction () throws SomeException {
// the codes go here.
………
if( a > b){ throw new SomeException ();
…………..
}
We can catch exceptions and provide a mechanism which will function when an Exception occurs using the try-catch block.
The code which can throw an Exception goes in the try block and the code for what we need to do if the Exception is caught goes in the catch block.
We can have multiple try catch blocks.
For every catch block there must be one and only one try block.
For every try block there must be at least one catch block or a finally block.
We can also have nested try-catch blocks if need arises.
Following is an example showing the syntax of a general try catch block:
……………………………
try{
//the code which is capable of throwing an Exception comes here.
…………………………………..
}
catch (SomeException1 se1) {
// the code for handling when the Exception of type SomeException1 in the try block comes here.
}
catch (SomeException2 se2) {
// the code for handling when the Exception of type SomeException2 in the try block comes here.
}
……………………………
If we want that some code should execute compulsorily even if the exceptions occur or not, then we can put in the finally block.
……………………………
try{
//the code which is capable of throwing an Exception comes here.
…………………………………..
}
catch (SomeException1 se1) {
// the code for handling when the Exception of type SomeException1 in the try block comes here.
}
catch (SomeException2 se2) {
// the code for handling when the Exception of type SomeException2 in the try block comes here.
}
finally{
// the code that needs to be executed compulsorily comes here.
}
The best programming practice says that we must put all the code that requires exception handling in try catch block and should not skip or ignore any such thing.
The best Exception handling practice says that when we catch exceptions, we must provide the catch blocks for those exceptions first that is most specific and then goes up the hierarchy and provide a catch block for more general exceptions.
1 comment:
Can u tell me anything about pointers in c++... my concepts are not clear..
Post a Comment