Use Exceptions Rather Than Return Codes
Back in the distant past there were many languages that didn't have exceptions.In those languages the techniques for handling and reportiing errors were limited.You either set an error flag or returned an error code that caller could check.The problem with these approaches is that they clutter the caller.The caller must check for errors immediately after the call.Unfortunately, it's easy to forget.For this reason it is better to throw an exception when you encounter an error.
Write your Try-Catch-Finally Statement First
One of the most insteresting things about exceptions is that they define a scope within your program.When you execute code in the try portion of a try-catch-finally statement,you are stating that execution can abort at any point and then resume at the catch.In a way, try blocks are like transactions.Your catch has to leave your program in a consistent state,no matter what happens in the try.For this reason it is good practice to start with a try-catch-finally statement when you are writting code that could throw exception.This helps you define what the user of that code should expect,no matter what goes wrong with the code that is executed in the try.
Try to write tests that force exceptions,and then add behavior to your handler to satisfy your tests.This will cause you to build the transaction scope of the try block first and will help you maintain the transaction nature of that scope.
Use Unchecked Exceptions
We have to decide-really-whether checked exceptions are worth their price.The price of checked exceptions is an Open/Closed Principle violation.If you throw a checked exception from a method in your code and the catch is three levels above, you must declare that exception in the signature of each method between you and the catch.This means that a change at a low level of the software can force signature changes on many higher levels.The change modules must be rebuilt and redeployed even though nothing they care about change.
Checked exceptions can sometimes be useful if you are writing a critical library: You must catche them.But in general application development the dependency costs outweight the benefits.
Provide Context with Exceptions
Each exception that you throw should provide enough context to determine the source and location of an error.In Java, you can get a stack trace from any exception;however, a stack trace can't tell you the intent of the operation that failed.
Create information error messages and pass them along with your exceptions.Mention the operation that failed and the type of failture.If you are logging in your application, pass along enough information to be able to log the error in your catch.
Define Exception Classes in Terms of a Caller's Needs
There are many ways to classify errors.We can classify them by their source:Did they come from one component or another?Or their type:Are they device failures,network failures, or programming errors?However, when we define exception classes in an application,our most important concern should be how they are caught.
Wrappers can be very useful.In fact, wrapping third-party APIs is a best practice.When you wrap a third-party API,you minimize your dependencies upon it:You can choose to move to a different library in the future without much penalty.Wrapping also makes it easier to mock out third-party calls when you are testing your own code.
One final advantage of wrapping is that you aren't tired to a particular vendor's API design choices.You can define an API that you fell comfortable with.Often a single exception class is fine for a particular area of code.The information sent with the exception can distinguish the errors.Use different classes only if there are times when you want to catch one exception and allow the other one to pass through.
Define the Normal Flow
If you follow the advice in the preceding sections, you'll end up with a good amount of separation between your business logic and your error handling.The bulk of your code will start to look like a clean unadorned algorithm.However,the process of doing this pushes error detection to the edges of your program.You wrap external APIs so that you can throw your own exceptions, and you define a handler above your code so that you can deal with any aborted computation.Most of the time this is a great approach,but there are some times when you may not want to abort.
Sometimes you create a class or configure an object so that it handles a special case for you.When you do, the client code doesn't have to deal with exceptional behavior.That behavior is encapsulated in the special case object.
Don't Return Null
I think that any discussion about error handling should include mention of the things we do that invite errors.The first on the list is returning null.I can't begin to count the number of applications I've seen in which nearly every other line was a check for null.
When we return null, we are essentially creating work for ourselves and foisting problems upon our callers.All it takes is one missing null check to send an application spinning out of control.
Don't Pass Null
Returning null from methods is bad,but passing null into methods is worse.Unless you are working with an API wichi expects you to pass null,you shoud aviod passing null in your code whenever possible.
In most programming languages there is no good way to deal with a null that is passed by a caller accidentally.Because this is the case,the rational approach is to forbid passing null by default.When you do, you can code with the knowledge taht a null in an argument list is an indication of a problem, and end up with far fewer careless mistakes.