¿Debería informar el texto del mensaje de las excepciones?

Question

Considere algunos códigos que pueden arrojar una excepción marcada (una excepción de tipo Exception). Su código catch es la excepción, por supuesto. No solo se traga la excepción tampoco, su código lo informa de alguna manera al usuario a través de su interfaz de usuario. En un archivo de registro, tal vez, o usando una ventana emergente de GUI.

En caso de que el texto que informe al usuario incluya el texto del mensaje de la excepción. Es decir, el texto proporcionado por Throwable.getMessage() o Throwable.getLocalizedMessage()?

Creo que no, pero parece que muchos no están de acuerdo conmigo. Entonces, ¿qué tengo mal? Mi argumento es el siguiente.

• El mensaje se creó cuando se produjo la excepción. Por lo tanto, en el mejor de los casos puede proporcionar información de muy bajo nivel, lo que puede ser inapropiado para informar a un usuario.
• Filosóficamente, usar el mensaje me parece contra todo el punto de excepciones, que es separar la detección y el inicio de la gestión de errores (la parte throw) desde la finalización de la gestión y la creación de informes (la parte catch). Usar el mensaje significa que el mensaje debe ser bueno para informar, lo que mueve la responsabilidad de informar a la ubicación que debería ser responsable únicamente de la detección e iniciación. Es decir, yo diría que la parte getMessage() del diseño de Throwable fue un error.
• El mensaje no está localizado. A pesar de su nombre, getLocalizedMessage() no es muy bueno porque es posible que no sepa qué configuración regional desea utilizar hasta que catch la excepción (es el informe para ir a un registro del sistema leído por los administradores del sistema inglés, o es para aparecer en un ventana para el usuario francés de la GUI?).
• Me enteré de que Java 7 tiene una jerarquía de excepción muy mejorada para IOException, lo que le permite manejar diferentes tipos de errores de E/S en las diferentes cláusulas catch, por lo que el texto getMessage() es menos importante. Eso implica que incluso los diseñadores de Java son algo incómodos con getMessage().

---

No estoy preguntando si la pila de informes-trace es útil. Un seguimiento de pila solo será útil para una excepción que sugiera un error. Es decir, para una excepción sin marcar. Creo que en tales circunstancias, proporcionar los detalles de bajo nivel del mensaje de excepción no es solo útil sino obligatorio. Pero mi pregunta se refiere a las excepciones comprobadas, como el archivo no encontrado.

Answer 1

No, las excepciones no se deben mostrar directamente en los mensajes de error directamente al usuario, son detalles técnicos de bajo nivel y el usuario casi siempre quiere algo más comprensible, incluso si no proporciona tanta información como rastro de pila lo haría!

Digo casi siempre porque hay casos (como en IDEs) en los que puede considerar a sus usuarios lo suficientemente competentes desde el punto de vista técnico como para observar los rastros de pila; de hecho, en este caso probablemente lo prefieran a un mensaje de error "simplificado".

Sin embargo, personalmente creo que los rastros de pila siempre deben registrarse en algún lugar al que el usuario pueda acceder para que si se quejan de que "el programa no funciona" pueda ver exactamente qué sucedió si le envían ese archivo.

Answer 2

Si está presentando una condición de error para el usuario, probablemente debería ser un mensaje fácil de usar. Las excepciones contienen detalles técnicos que el usuario no debe/no necesita saber.

En algunas situaciones, puede ser una preocupación de seguridad presentar información de pila, por lo que al usuario nunca se le deben mostrar los rastros de pila.

Si muestra mensajes de error al usuario, hay un momento en el que conscientemente toma la decisión de mostrar una ventana emergente o agrega un mensaje a una ventana de registro. En ese momento, puede traducir cualquier excepción en un mensaje más fácil de usar. Tenga en cuenta que es posible que necesite más información de la que proporcionan los tipos Exception predeterminados, por lo que puede/debe probablemente crear sus propios tipos Exception que contengan toda la información que necesita para presentar todos los datos que necesita al usuario.

Answer 3

En algunos proyectos, hago un tipo especial de excepción (por ejemplo, UserFriendlyException). Este tipo de excepción debe tener un mensaje de error fácil de usar.Si capturo una excepción, puedo mostrarla al usuario.

Esto hace posible usar excepciones para errores fáciles de usar y evita que muestre mensajes muy técnicos al usuario.

Answer 4

Argumentaría que nunca debería mostrarse el mensaje de excepción al usuario, solo debería aparecer en un registro. Incluso si lo has hecho fácil de usar, aún no debería mostrarse porque no puedes internacionalizar esos mensajes fácilmente. Debería encontrar algún mecanismo que su capa de interfaz de usuario pueda comprender y resolver en un código para que pueda consultar un mensaje internacionalizado que se mostrará a su usuario. Descubrí que una excepción con un atributo/enum de "código" funciona bastante bien. Las excepciones muy específicas también funcionan, pero eso puede ser complicado de mantener.