This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I know a lot has been written about this subject and I have tried to educate myself. The API and most people, it seems, state that you should not catch an error because they are too serious to recover from. But some people make exceptions, and I am unsure about my situation.
I have a small web application that accesses and updates MySQL without pooled connections and sends out emails from time-to-time using multiple threads. This is the general form of my servlets:
Is trying to catch an error like this a reasonable approach? Will it even work? If I stop doing this in my servlets, what will happen if an error occurs?
IMO, it is useful to know what is going wrong in at very high level . so some time, you can even catch some Error (for instance AssertionError) , though it is not recommended in javadoc.
I would have replace
Are you going to recover from the exception in some way? By providing a default in case of failure, perhaps? Retry an operation? Some other recovery scheme?
If not, then don't catch it. All you're doing in that case is getting in the way.
Define a top-level error handler in the deployment descriptor and let it log any exceptions and send the user to a customer-facing page that explains that the error occurs. Under no circustances expose the user to something like a stack trace.
I'm not sure whether your question is directed to me or Mr. Venkatasamy. After I close resources and invalidate the session, I send the user to a JSP with "A system error interrupted processing ..."
But, no, I don't try to recover from the error itself.