Friday, February 1, 2013

Deterministic Error Handling Win

I love this article about the different Java Exception types:

  http://johnpwood.net/2008/04/21/java-checked-exceptions-vs-runtime-exceptions/
 
Something that I realized some time ago(in after thought), is that if you provide enough Application functionality to be considered an API, using a RuntimeException master class can really help in debugging what occurs in each API call. You don't need to have all the messy throws statements cluttering up your methods, if the whole purpose of having them is to return an Error State. In an API it can help to know just what happened in a call deep in the hierarchy, and be able to trace back the error. An ErrorCode type RuntimeException can pass back additional information about the error, and even the unexpected Exception itself for cross analysis, at an API exit point. Logging all this information at a single API exit point then also provides a specific location where, you can hand off the error to the caller, and also provide a debugging snippet that describes just what occurred. In a high performance application where having errors occur is not an option, knowing what happened when an error does occur is very important. Instant visibility into unexpected cases is important, while pre-determined error states are simple to log/record, unexpected error states should provide for copious debugging information so you can determine exactly what expected actions occurred. One piece of advice I have for everyone is do not under estimate the importance of debugging and logging. If your application needs to know each error state, then even the unexplained errors can be logged well to determine application state/performance/failure etc.

No comments: