Clever Geek Handbook

J2EE Error Handling - Application and User

I have a question regarding error handling in a J2EE application. Our real application is used by many users and we receive many support tickets as a result. Most of these tickets are user-related, but 5-10% are system-related exceptions, unhandled errors, etc.

We have basic exception handling checks in code (work needs), but from my experience showing a generic message to the user, it doesn't speed up the troubleshooting process.

I'm looking for a recommendation on a good error handling design pattern to consider the scenario:

  • The code has an error
  • Error in progress
  • The user is presented with a non-technical error message with a specific error code.
  • A non-technical support team can use this error code to see the area (page, section, ..) in the application where this happened and what the user might be doing (information provided by the development team in the customer support help guide).
  • The tech support team can use zero-level code right in the class / JSP, etc. and the line of code that caused this exception.
  • We use a logging module where most (not all) Tomcat stdout errors are logged by the user session ... to the error code the user receives, we can include the log id if it exists, and also so the tech team can look at this too.

Basically, what I'm interested in is shortening the support-explain-research analysis cycle and giving each department access to information at their fingertips that can speed them up for their respective assignments:

  • Customer support can provide a comprehensive explanation for this error code or alternative steps that the user can follow.
  • The tech team can start troubleshooting a line of code or what the user is doing that caused that line.

The necessary error code triggers for the next steps for each department and actually reduce the problem investigation phase and move on to the solution phase.

I'm not sure if this is even a good idea. Any suggestions will be appreciated on a good "design blueprint" for such a need. Or if this was a good route to take a look at.

Thanks in advance.

SP

0


source to share


2 answers


It looks like you need to spend some serious time playing out your support issues for some sort of code. My experience is that you can almost always create a “top 10 list” of items that cause 50% + of support issues. After you hit the first 10, review the call logs. Data is required.

A program dedicated to solving support problems and knocking them out of the park should be able to quickly get problems with code out. After that, you will be left with humanity / usability issues that need to be handled through training, experience, or generally a longer term workflow / usability redesign.



If you get hammered in bugs that you think you need to develop a list of error codes / conditions for, it sounds like your product needs another 6 months to stabilize. You are probably not developing an OS, and for 99% of projects developing the IBMesque error blackbook, there is no model for emulation.

+2


source


Use log4j to log all errors and exceptions to the logger that sends you information. Don't worry about custom messaging; all they need to know was there was a mistake and that it was recorded.



0


source






More articles:


All Articles