I'm at a point in my small project where I need to start filling in the parts when thing break, fail, or just don't work. But I am a bit unclear on the best ways to handle exceptions in classes from servlets.
For example, I have several servlets that access java objects that interract with the database. Currently, if there is an exception for any reason, I print the stack trace to the console but my app just continues. What I need to do is elagantly inform the user that an exception has occurred and that they should try again and/or contact the administrator (me) about the issue. Or better yet, maybe I should just get an Email of the exception when it occurs as well as what I just mentioned above.
So does anyone have any techniques, war stories, and/or general advice on how to do this?
Generally you would let the exception propogate outwards and get handled by a servlet or page that you can set up in the web.xml file as an error handler (in fact, you can specify separate resources to handle different exceptions or error types).
This servlet cvould perform any processing you like, and then forward to a "we're very sorry" page.
Note: if you get to a location in the code where all you can throw is a ServletException or JspException, these types are meant to be "container exceptions" which can wrap the original exception as the "root cause".
You are saying that you have a few Java objects that make database access and you have several servlets that access these Java objects. Now, as suggested by the replies by a few members above, let those Java objects only propagate the exception so that you can handle those exceptions at the servlet level. Then, you can have a seperate Java class that uses classes from the JavaMail API. You can use this class to send an e-mail to anyone you choose whenever an exception occurs.
From your servlet, as soon as you catch an exception, you can create this new Mailing object, set the To address and you can have the message body to be the complete exception stack trace. So, the e-mail can be sent to anyone you wish this way. If you carefully tweak around this new Java class that you write so that its pretty generic enough, you will be able to use it in any of your future projects as well, that is, wherever you will need a mailing facaility.
Vijayendra <br /> <br />"The harder you train in peace, the lesser you bleed in war"
I have a somewhat similar situation, what I have done for now, is create an heirarchy of error-handling pages.
Say, a subset of JSP's makes a component logically. I will have an error page for that component, which tries to handle the exceptions it can understand, which would be usually be component-specific exception classes I have created. This page will try to give the user a meaningful message, and ask them to try again.
Any exceptions that it cannot understand, it rethrows, and are passed on to the 'error-page' JSP specified in web.xml.
This highest level error-hanlding JSP just informs the user that something went wrong, and give a link to go back. By the time I finish, on this page I will have an option for the user to report it as a bug through email.
Still looking for ways to make it all streamlined, the biggest pain are the SQLExceptions, with database specific error-codes.
Thanks for all the suggestions. I'll be doing some testing when I am at work today.
Sonny, I am right there with you. I am less concerned about ServletExceptions because I really don't have enough code in my servlets for them to throw an exception unless something happens to my request object for some reason.
I am more concerned with my SQLExceptions and how to get those back to the Servlet to handle the error and in an elegant way for the user.
Gregg, have you ever looked at Spring? Its JDBC support classes use an exception translator to turn each SQLException into an exception from the DAO exception hierarchy. The advantages are twofold: first, other than SQLException, the DAO exceptions are structured so you can catch specific problems using a bog standard catch clause; second, they are RuntimeExceptions so you if you cannot handle an exception in your method (which is most of the time) you can simply allow it to propagate out and catch it using an error page at the web-app level - no cluttered throws clause or further wrapping required.
Since all parts of the Spring framework are useable independently, there is nothing stopping you from using the translator in your application and nothing else. It will take you all of ten minutes. In the slightly longer term I would strongly encourage you to explore the bean container and JDBC template though. I've been using Spring for a year now, and it is awesome.
- Peter [ July 31, 2004: Message edited by: Peter den Haan ]