What are the errors which a web appln should tell the users ? For an example,if a user tries to login by giving 'login' and password, there are many steps taken at the server side. First I validate the form inputs, then check the given 'login' and 'password' against the ones in the database, and then route to corresponding pages depending on if the login is success or failed. So in course of all these actions there mignt be many types of Exceptions would have been raised some are checked and some are un-checked(Runtime). For ex. SQLException/NullPointerException and others. For some exception, the user's input may be the cause and for others, it might be coding/or other problems. What are the exception we should inform the user? Should we repharse the wording of the Exception messages? What are the exceptions should we try to catch? I understand we should do very aggressive testing before we put our web appln online. But I wonder what are the ones we should notify the users. If we just caught an exception and NOT inform the user of anything at all the user will see a BLANK page. This is also not good. For example NullPointerException etc. Should we tell the user about this prob and ask to contact the Admin? If we TEST the web appln properly, then there should not be any need for taking care of a Runtime Exception I think. Can you share your experiences in this reagrd? Also where do you all log the errors? Do you use 'getServletContext.log(....)' API? Thank you very much. regds maha anna
For exceptions caught in doGet or doPost, I typically generate an HTML page with the stack trace and a request that the user grab the screen contents and email me. Not too elegant but at least the user has a feeling that he is accomplishing something. A blank screen or a 404 error is the worst! With JRun I log errors to System.err which JRun nicely maps to a file. Bill
Hi Maha, Instead of displaying all Exceptions or Stacktrace to the user catch all type of exceptions in the servlet and write them into a log file, then forward the request to an error.jsp file which tells user something understandable message. Even you can pass different messages based on the Exceptions you got and let error.jsp display that to user. If the user is the technical guy, then he/she understands the Exceptions and he/she will be knowing all your class structure which may not be good. If the user is not technical then he will be confused with Exceptions. Am I right?
From an overall engineering/usability standpoint, a general rule of thumb can be applied. 1) if the user can resolve the error (ie. malformed email address in a form) then catch this error and return an error message informing them as such - not a stack trace. 2) if the error is not user generated (ie. bad DB connection, etc) then handle it internally and redirect the user to a generic error page. A nice way to handle this is to have a super class servlet that will catch any exception and then display a nicely formated page. Have your other servlets extend this and, if an exception occurs, decide what to do based on the above 'rules'. If it's rule #2, simply let the exception go uncaught so that the super class servlet can catch it and display the generic error page. You can enhance this by creating and throwing custom exceptions that can be filtered in the super class servlet and display any number of generic error pages according to the custom exception caught (ie. problem with cookies, db, etc). Hope this helps. Sean
subject: The TYPES OF ERRORS should be returned to users by Web Appln.