we have an errorPage directive in our top level jsp.
<%@ page language=“java” errorPage=“myError.jsp” %>
(myError.jsp does some very general error handling. In addition to putting up a default page it sends email to a support team)
Is there anyway to replace the top-level catch mechanism for uncaught jsp errors?
Thanks,
-pf
Looks like multiple levels of error handling are possible.
Actually, my question was more about intercepting/replacing the catch mechanism in the IDACall servlet. We have many DMI classes and if possible would like a single place to catch any uncaught errors thrown from the DMI calls.
-p
The default IDACall servlet already catches all Exceptions and returns them as RPCResponses / DSResponses with a failure status.
Are you seeing some other behavior or are you trying to change this behavior?
We are trying to change this behavior. The basic idea is to have one place to catch all DMI server exceptions and execute a basic error handler that does some book keeping (sends email to support with a stack trace, and puts up a default error jsp with a link the user can click on to provide additional information as to what they were doing when the exception occured).
-p
Redirecting to a .jsp destroys the current application, which seems like bad handling, since this would mean an intermittent error would wipe out unsaved changes and other application context.
Better handling (client-side) would be to add some logic to RPCManager.handleError so that the errors that wind up there offer a link to an error page or provide whatever additional hand-holding you want. This gives the user a chance to proceed with whatever they were doing if the error is just that the database is down for a while.
For errors you know are completely fatal and should wipe out the current application state, within handleError you can still redirect the whole page to a .jsp.
Finally, about wanting some common server-side logic like sending an email - one way to share such logic is to have a base class your DMI classes all subclass from. Another is to move logic that is really data layer handling into a reusable custom DataSource class.