Eventually, your application will work the way you want. But things can still go wrong due to problems with external systems your application depends on, such as a database. And even though you have tested and debugged your application, there may be runtime conditions you didn’t anticipate.
Well-behaved components, such as beans and JSP actions, deal with
expected error conditions in a graceful manner. For instance, the
UserInfo bean used in Chapter 8
valid attribute that is
false unless all properties are set to valid
values. Your JSP page can then test the property value and present
the user with an appropriate message. The JSTL actions also act
gracefully in most situations, for instance the
<c:forEach> action simply does nothing if
items attribute value is
Some problems are impossible for the component to handle gracefully, however, and the user needs to be told about the problem instead. The standard way Java does this is to throw an exception. Beans, JSP actions, and the EL processor, can throw exceptions when something goes really bad. By default, the JSP container catches the exception and displays its message and stack trace in the browser, similar to what’s shown in Figure 9-1. But that’s hardly the type of error message you want the application users to see. Besides, the exception messages may reveal information that can be sensitive from a security point of view, such as file paths and SQL statements. You can present a much ...