General rules

1. Use of RuntimeException derived Exceptions: As a general rule, applications Exceptions must be derived from RuntimeException. RuntimeException s do not force Exceptions to be caught and handled at compile time. This strategy does not encourage developers to catch Java's base Exception class in response to numerous exceptions thrown by underlying code. The general consensus among the Middleware team was that if unchecked exceptions are thrown instead of checked exceptions, there is a greater chance that the application errors are reported and not eaten up by catching Java base Exception classes.
2. Preserve Encapsulation across modules/packages: Exceptions in throws clause of public methods should belong to the package of the called method. Within modules/packages, distinctive exceptions can be used. Exceptions from other packages are wrapped into current package exceptions and propagated.
   
   Homogenize exceptions at package boundaries. Create a base Runtime exception at the module/package boundaries. Convert all exceptions propagated from inside to the top-level package classes, to the base package exception type. This way, even if more exceptions are added later inside the package, the caller code does not need to change.
   
   Refine Exceptions in order to preserve package stability and to derive more meaningful exceptions inside the package. This can be accomplished by sub-classing the base package exceptions to more meaningful exceptions.
3. Document Exceptions in Javadocs, method signatures and unit tests. Incorporating Runtime Exceptions in the throws clause of method signatures highlights exceptions so that they can be handled by client code developers but at the same time, do not impose restrictions of checked exception handling.
4. Use nested exceptions to include references to earlier causes.
5. Do not eat Exceptions by having empty catch blocks.
6. Do not catch top-level exceptions i.e. catching Exception class. This has the unintended consequence of catching RuntimeException s.
7. Log once. Numerous logs for same exception while handling propagated exceptions cause confusion.
8. Do not use Exceptions for flow control

Use struts declarative exception handling for actions

Let's use the declarative way to specifying exception in actions as much as possible.

Read Jakarta Struts:. Declarative Exception. Handling for a quick tutorial.

Implementation note Often an exception message includes a contextual variable element: the name of the sheet that wasn't found, the name of the column with the wrong data... By default struts declarative handling does not support it. However it provides an extension point with ExceptionHandler. We need to create a custom exception handler that locate a property in the Property Bundle with exception.<full-qualified-class-name>, replace any {xxx} its associated text with the value of the exception xxx property. We should handle silently when an exception text referenced an unknown property but we should log it. Next time somebody estimate a story with a new action, let's put it in the estimate and let's start to clean up our action from exception code! BTW eventually that handler logic should be available to other than struts client (SOAP for example). So keep the struts code as encapsulated as possible like we always should do in action logic.