|
JAVA Interview Questions 36 - 39
|
Back to the list of all Java Interview Questions
|
|
Question 36: Why is it not advisable to catch type “Exception”?
|
Exception handling in Java is polymorphic in nature. For example if you catch type Exception in your code then it
can catch or throw its descendent types like IOException as well. So if you catch the type Exception before the
type IOException then the type Exception block will catch the entire exceptions and type IOException block is
never reached. In order to catch the type IOException and handle it differently to type Exception, IOException
should be caught first (remember that you can’t have a bigger basket above a smaller basket).
|
|
The diagram above is an example for illustration only. In practice it is not recommended to catch type
“Exception”. We should only catch specific subtypes of the Exception class. Having a bigger basket (i.e.
Exception) will hide or cause problems. Since the RunTimeException is a subtype of Exception, catching the type
Exception will catch all the run time exceptions (like NullPointerException, ArrayIndexOutOfBoundsException) as
well.
Example:
The FileNotFoundException is extended (i.e. inherited) from the IOException. So (subclasses have to
be caught first) FileNotFoundException (small basket) should be caught before IOException (big basket).
|
|
Question 37: Why should you throw an exception early?
|
The exception stack trace helps you pinpoint where an exception occurred by showing you the exact sequence of
method calls that lead to the exception. By throwing your exception early, the exception becomes more accurate
and more specific. Avoid suppressing or ignoring exceptions. Also avoid using exceptions just to get a flow control.
Instead of:
|
|
// assume this line throws an exception because filename == null.
InputStream in = new FileInputStream(fileName);
…
|
|
Use the following code because you get a more accurate stack trace:
|
|
…
if(filename == null) {
throw new IllegalArgumentException(“file name is null”);
}
InputStream in = new FileInputStream(fileName);
…
|
Question 38: Why should you catch a checked exception late in a catch {} block?
|
You should not try to catch the exception before your program can handle it in an appropriate manner. The natural
tendency when a compiler complains about a checked exception is to catch it so that the compiler stops reporting
errors. It is a bad practice to sweep the exceptions under the carpet by catching it and not doing anything with it.
The best practice is to catch the exception at the appropriate layer (e.g. an exception thrown at an integration layer
can be caught at a presentation layer in a catch {} block), where your program can either meaningfully recover
from the exception and continue to execute or log the exception only once in detail, so that user can identify the
cause of the exception.
|
|
Question 39: When should you use a checked exception and when should you use an unchecked exception?
|
Due to heavy use of checked exceptions and minimal use of unchecked exceptions, there has been a hot debate
in the Java community regarding true value of checked exceptions. Use checked exceptions when the client code
can take some useful recovery action based on information in exception. Use unchecked exception when client
code cannot do anything. For example Convert your SQLException into another checked exception if the client
code can recover from it. Convert your SQLException into an unchecked (i.e. RuntimeException) exception, if the
client code can not recover from it. (Note: Hibernate 3 & Spring uses RuntimeExceptions prevalently).
Important:
throw an exception early and catch an exception late but do not sweep an exception under the carpet
by catching it and not doing anything with it. This will hide problems and it will be hard to debug and fix.
A note on key words for error handling:
|
throw / throws – used to pass an exception to the method that called it.
try – block of code will be tried but may cause an exception.
catch – declares the block of code, which handles the exception.
finally – block of code, which is always executed (except System.exit(0) call) no matter what program flow, occurs
when dealing with an exception.
assert – Evaluates a conditional expression to verify the programmer’s assumption.
|
Back to the list of all Java Interview Questions
|
