Exception Handling - Do's and Don’ts -Code for failures -Part-3

Part-1 is here...
Part-2 is here...

Do's and Don'ts in Exception Handling

1. Do not suppress the exception
2. Do catch the specific exception than the toplevel or generic exceptions
3. Do handle the thrown exception.
4. Do not throw the irrelevant exceptions to the caller
5. Do not handle the irrelevant exception by own.
6. Do Wrap-up the exception



1. Do not suppress the exception

try{

// File reading code here

}catch(IOException ioEx){

// do Nothing

}

Often we use try catch block in our code when compiler/IDE force as to handle the checked exceptions, we do write try catch block and just leave the catch block as
Empty, first of all we must handle these checked exceptions, that's the reason it has been forced by compilers, by leaving empty catch block, we defeat the purpose of these checked exceptions.

2. Do catch the specific exception than the top-level or generic exceptions

Catch the specific exceptions as much as possible; do not just catch the generic exceptions.

try{

// File reading code here

}catch(FileNotFoundException fnfEx){

// do something

}catch(IOException ioEx){

// do something

}catch(Exception ex){

// do something

}


3. Do handle the thrown exception.

Compiler won't force us to handle the unchecked exceptions, it doesn't mean we no need to handle, for the good exceptiona handling must handle all the exceptions as much as possible.


4. Do not throw the irrelevant / unknown exceptions to the caller

This is one of the important point in exception handling, code shouldn't throw all the exceptions to the caller, if any exception which can be handled by own, that exceptions must be handled then and there, for example, a method is trying to connect to Database and it throws Connection Could not established exception, then code should not throw this to handler, the method must handle and do some recoveries like re try or try to connect to the alternate Database. the caller may not know what to do with this exception, so this must be handled then and there.


5. Do not handle the irrelevant exception by own.

Like the above point, the code must not handle the exceptions which are not relevant to that piece, it should throw the exception to the caller.


6. Do Wrap-up the exception

From the bottom to top, if the code throws all the exceptions as it is, the top level must handle or know about too many exceptions, so must wrapper the exceptions, log down it and pass to the above layer.

For example, if DAO layer got some exception like SQLExcpetion, the end user or UI not necessarily say what is the error, instead this code wrap up as SystemException and pass it to the above layer, even though wrap that to system exception it should be logged down properly in the log files as SQLException, otherwise developer or operation people get confused about the exceptions.