Manejo de errores J2EE - Aplicación y usuario

Question

Tengo una pregunta sobre el manejo de errores en una aplicación J2EE. Nuestra aplicación actual está en uso por muchos usuarios y, como resultado, recibimos muchos tickets de soporte. La mayoría de estos tickets están relacionados con el usuario, pero el 5-10% son excepciones relacionadas con el sistema, errores no controlados, etc.

Tenemos las comprobaciones básicas de manejo de excepciones en el código (necesita trabajos), pero desde mi experiencia, mostrar un mensaje genérico al usuario no ayuda a acelerar el proceso de solución de problemas.

Lo que estoy buscando es una recomendación sobre un buen patrón de diseño de manejo de errores para que consideremos un escenario:

1. El código tiene un error
2. Se maneja el error
3. Se muestra al usuario un mensaje de error no técnico con un código de error específico.
4. El equipo de soporte no técnico puede usar este código de error para ver el área (página, sección, ..) en la aplicación donde sucedió esto y lo que el usuario podría haber estado haciendo (información previamente rellenada por el equipo de desarrollo en una referencia de soporte al cliente guía).
5. El equipo de soporte técnico puede usar el código para centrarse directamente en la clase / JSP, etc. y la línea de código que desencadenó esa excepción.
6. Utilizamos un módulo de registro donde la mayoría (no todos) los errores stdout de Tomcat se registran por sesión de usuario ... al código de error que recibirá el usuario podemos incluir la ID de registro si existe como bueno para que el equipo de tecnología pueda ver eso también.

Básicamente, lo que me interesa es reducir el ciclo de análisis, explicación e investigación de soporte y dar a cada departamento acceso a la información a su alcance, lo que puede ayudarlos a comenzar más rápido para sus respectivos trabajos:

1. El servicio de atención al cliente puede dar una explicación general de este código de error o puede tener pasos alternativos que el usuario podría seguir.
2. El equipo técnico podría comenzar a solucionar la línea de código o lo que estaba haciendo el usuario que activó esa línea.

Esencial cada código de error desencadena los siguientes pasos necesarios para cada departamento y, en efecto, reduce la fase de investigación del problema y pasa a la fase de solución.

No estoy seguro de si lo anterior es incluso una buena idea. Cualquier sugerencia sería apreciada en un buen patrón de diseño para tal necesidad O si incluso fuera una buena ruta para mirar.

Gracias de antemano.

SP

Answer 1

Parece que necesita pasar un tiempo serio acumulando sus problemas de soporte para un triaje de código. Mi experiencia ha sido que casi siempre puedes crear una "lista de los 10 principales". de elementos que causan más del 50% de los problemas de soporte. Después de haber eliminado los primeros 10, vuelva a examinar los registros de llamadas. Los datos son imprescindibles.

Un programa dedicado a abordar los problemas de soporte y eliminarlos del parque debería poder eliminar los problemas de código con bastante rapidez. Después de lo cual, se quedará con problemas humanos / usabilidad que deben manejarse con capacitación, experiencia o, por lo general, algunas refactorizaciones de flujo de trabajo / usabilidad a más largo plazo.

Si está abrumado por errores para los que cree que necesita desarrollar una lista de códigos / condiciones de error, parece que su producto necesita otros 6 meses de estabilización. Probablemente no desarrolle un sistema operativo, y para el 99% de los proyectos que desarrollan un libro negro de códigos de error IBMesque no es el modelo a emular.

Answer 2

Use log4j para registrar todos los errores y excepciones en un registrador que le envíe la información por correo electrónico. No te preocupes por los mensajes de usuario; todo lo que necesitan saber es que hubo un error y que se registró.