Tying Up the Loose Ends

Before we leave the topic of exception handling, there are several special cases that we should discuss. Each one of these is unique, and you may or may not need them in your applications.

Handling Remote Exceptions

Remote Java objects are allowed to throw instances of java.rmi.RemoteException. In fact, every EJB method that is exposed to a remote client must declare that it throws RemoteException. Dealing with RemoteExceptions is very similar to handling system exceptions except that they are not descendants of either java.lang.Error or java.lang.RuntimeException.

Often, the application will not be able to recover from a RemoteException and will have to display the system error page. If you’re using EJB and you get a RemoteException, you can attempt to recover by acquiring a new remote reference, but there’s probably some type of programming or environment error that will prevent the end user from continuing. Whether you’re using a programmatic or a declarative approach, you’ll likely want to log the exception, create and store an ActionError object, and then forward to the system error page. You can also define the exception-handling behavior to forward the user back to the previous page and give her the choice of trying again. If some type of network blip caused the remote exception, it may be possible for the user to continue to use the application.

Exceptions in Custom Tags

JSP custom tags usually throw JSPException objects or one of their descendants. ...

Get Programming Jakarta Struts, Second Edition now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.