The problem statement (if you are interested)
Java is the first OO language to force handling exceptions by way of checked exceptions. It is also possible to encounter unchecked or RuntimeException s in Java which do not explicitly outline the contract between a method and it's callers. Both Checked and Unchecked exceptions extend from base Exception class in java.lang package.
In this write-up, some issues relating to exceptions design & handling are discussed and guidelines are suggested to alleviate some of the incoherence and confusion that can result when dealing with exceptions.
Issues
When do you throw RuntimeException Vs Checked Exception?
Checked Exceptions introduce tight coupling between a method and it's direct & indirect callers. On the other hand throwing RuntimeException s could result in unintended catastrophic failures at the client level at runtime unless these exceptions are caught and handled by the caller code.
Do we catch RuntimeExceptions?
RuntimeException s is generally thrown for programmatic errors. If these Errors can potentially cause severe negative effects, a RuntimeException handling strategy must be adopted that is best suited for the software's context.
How do we preserve Encapsulation?
When classes re-throw exceptions caught when calling methods on classes from other packages/components, the client code will have to deal with exceptions from packages that were not directly called resulting in incoherent code.
Labels