However, in real Web applications you
should rarely if ever rely on this mechanism to catch exceptions. All exceptions
should be caught explicitly in your code.
To use the web.xml way of catching exceptions, you only need to supply two
things: a fully qualified exception class and a location, as shown here.
package.ClassName
/SomeURL
Then, if any servlet or JSP page in the Web application generates an uncaught
exception of the specified type, the designated URL is used. The exception type can
be a standard one like javax.ServletException or java.lang.OutOf-
MemoryError, or it can be an exception specific to your application.
For instance, Listing 2.19 shows an exception class named DumbDeveloper-
Exception that might be used to flag particularly bad mistakes by clueless programmers
(not that you have any of those types on your development team). The
class also contains a static method called dangerousComputation that sometimes
generates this type of exception. Listing 2.20 shows a JSP page that calls dangerous-
Computation on random integer values. When the exception is thrown, DDE.jsp
(Listing 2.21) is displayed to the client, as designated by the exception-type entry
shown in the web.xml version of Listing 2.22. Figures 2??“20 and 2??“21 show lucky and
unlucky results, respectively.
Listing 2.19 DumbDeveloperException.
Pages:
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115