title: J2EE Error Handling - Application and User
body: <p>I have a question regarding handling errors in a J2EE application. Our current application is in use by many many users and as a result we get a lot of support tickets. Most of these tickets are user-related but 5-10% are system related exceptions, unhandled errors, etc.</p>
  
  <p>We have the basic exception handling checks in the code (needs works), but from my experience showing a generic message to the user doesn't help the troubleshooting process to be expedited. </p>
  
  <p>What I'm looking for is a recommendation on a good error handling design pattern so that let's consider a scenario:</p>
  
  <ol>
  <li>Code has an error</li>
  <li>Error is handled</li>
  <li>User is shown a non-technical error message with a specific error code.</li>
  <li>Non-tech Support team can use this error code to see the area (page, section, ..) in the application where this happened and what the user might have been doing (information prepopulated by dev team in a customer support reference guide).</li>
  <li>Tech support team can use the code to zero right in on the class/JSP etc and line of code which trigged that exception.</li>
  <li>We use a logging module where <em>most</em> (not all) Tomcat stdout errors are logged by user session ... to the error code the user will receive we can include the log ID if it exists as well so that the tech team can look at that too.</li>
  </ol>
  
  <p>Basically what I'm interested is to reduce the support analysis-explanation-research cycle and give every department access to the information at their fingertips which can get them started faster for their respective jobs:</p>
  
  <ol>
  <li>Customer support can give a canned explanation for this error code or have alternative steps the user could follow.</li>
  <li>Tech team could start troubleshooting the line of code or what the user was doing which triggered that line. </li>
  </ol>
  
  <p>Essential each error code triggers of the required next-steps for each department and in effect reducing the research phase of the issue and moving to the solution phase.</p>
  
  <p>I'm not sure if the above is even a good idea. Any suggestions would be appreciated on a good "design pattern" for such a need. Or if it would even be a good route to look at.</p>
  
  <p>Thanks in advance.</p>
  
  <p>SP</p>