Good Programming Practices - Error handling
Error handling is important to write clean, beautiful and elegant code, but it is also the most Overlooked skill.Use Exceptions Rather Than Return Codes
Provide Context with Exceptions
Create informative error messages and pass them along with your exceptions.
Exception chaining
Exception chaining is appropriate in cases where the lower-level exception might be helpful to someone debugging the problem that caused the higher-level exception. The lower-level exception (the cause) is passed to the higher-level exception, which provides an accessor method (Throwable.getCause) to retrieve the lower-level exception.
Define Exception Classes in Terms of a Caller’s Needs
Use wrapper class/method to wrap and simplify the third-party API that we are calling and make sure that it returns a common exception type suitable for our class.
Don’t Return Null
When we return null, we are foisting problems upon our callers. One missing null check may crash the application.
If you are tempted to return null from a method, consider throwing an exception or returning a SPECIAL CASE object instead.
Don’t Pass Null
Unless you are working with an API which expects you to pass null, you should avoid passing null in your code whenever possible.
Notes from Effective Java 2nd Section
Item 57: Use exceptions only for exceptional conditions
Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
Item 59: Avoid unnecessary use of checked exceptions
Item 60: Favor the use of standard exceptions
Item 61: Throw exceptions appropriate to the abstraction
Higher layers should catch lower-level exceptions and, in their place, throw exceptions that can be explained in terms of the higher-level abstraction.
Where possible, the best way to deal with exceptions from lower layers is to avoid them, by ensuring that lower-level methods succeed. Sometimes you can do this by checking the validity of the higher-level method’s parameters before passing them on to lower layers.
Item 62: Document all exceptions thrown by each method
Document every exception (checked or unchecked) that can be thrown by each method that you write, and document precisely the conditions under which each one is thrown using the Javadoc @throws tag.
Don’t take the shortcut of declaring that a method throws some superclass of multiple exception classes that it can throw, never declare a method that throws Exception or Throwable in a method.
Use the Javadoc @throws tag to document each unchecked exception that a method can throw, but do not use the throws keyword to include unchecked exceptions in the method declaration.
Item 63: Include failure-capture information in detail messages
To capture the failure, the detail message of an exception should contain the values of all parameters and fields that “contributed to the exception.”
Item 63: Include failure-capture information in detail messages
To capture the failure, the detail message of an exception should contain the values of all parameters and fields that “contributed to the exception.”
One way to ensure that exceptions contain adequate failure-capture information in their detail messages is to require this information in their constructors instead of a string detail message.
Item 64: Strive for failure atomicity
A failed method invocation should leave the object in the state that it was in prior to the invocation.
Ways to achieve failure atomicity:
1. Check parameters for validity before performing the operation. This causes any exception to get thrown before object modification commences.
2. Order the computation so that any part that may fail takes place before any part that modifies the object.
3. Perform the operation on a temporary copy of the object and to replace the contents of the object with the temporary copy once the operation is complete.
4. Write recovery code that intercepts a failure that occurs in the midst of an operation and causes the object to roll back its state to the point before the operation began. This approach is used mainly for durable (disk-based) data structures.
Item 65: Don’t ignore exceptionsResources:
Clean Code: A Handbook of Agile Software Craftsmanship
Effective Java (2nd Edition)
