Chapter 9: Struts and Exception Handling

In this chapter:

1. You will learn about basics of Exception Handling

2. You will understand the exception handling from servlet specification perspective

3. You will understand exception handling facilities in Struts1.1

4. We will develop a simple yet robust utility to log exceptions

5. We will cover strategies to centralize logging in production environments

Exception handling is very crucial part often overlooked in web application development that has ramifications far beyond deployment. You know how to handle exceptions using the built-in Java construct to catch one and handle it appropriately. But what is appropriate? The basic rationale behind exception handling is to catch errors and report them. What is the level of detail needed in reporting the exception? How should the user be notified of the exception? How should customer support handle problem reports and track and trace the exception from the logs? As a developer where do you handle the exceptions? These are some of the major questions we will answer in this chapter first from a generic way and then as applicable to Struts applications.

Under normal circumstances when you catch the exception in a method, you print the stack trace using the printStacktrace() method or declare the method to throw the exception. In a production system, when an exception is thrown it's likely that the system is unable to process end user ‚ s request. When such an exception occurs, the end user normally expects the following:

• A message indicating that an error has occurred

• A unique error identifier that he can use while reporting it to customer support.

• Quick resolution of the problem.

The customer support should have access to back-end mechanisms to resolve the problem. The customer service team should, for example, receive immediate error notification, so that the service representative is aware of the problem before the customer calls for resolution. Furthermore, the service representative should be able to use the unique error identifier ( reported by the user) to lookup the production log files for quick identification of the problem ‚ preferably up to the exact line number (or at least the exact method). In order to provide both the end user and the support team with the tools and services they need, you as a developer must have a clear picture, as you are building a system, of everything that can go wrong with it once it is deployed.