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

Considere algún código que pueda arrojar una excepción marcada (una excepción de tipo Exception ). Tu código 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.

Si el texto que informa al usuario incluye 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 lanzó 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 las excepciones, que es separar la detección y el inicio del manejo de errores (la parte throw ) de la finalización del manejo y la generació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 solo debería ser responsable 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 aparece? en una ventana para el usuario francés de la GUI?).
  • Escuché que Java 7 tiene una jerarquía de excepción mucho mejor para IOException , lo que le permite manejar diferentes clases de errores de E / S en cláusulas de catch , lo que hace que el texto de getMessage() menos importante. Eso implica que incluso los diseñadores de Java son algo incómodos con getMessage() .

No estoy preguntando si informar el stack-trace es útil. Un seguimiento de stack 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.

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 stack, por lo que al usuario nunca se le deben mostrar los rastros de stack.

Si está mostrando 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 de Exception predeterminados, por lo que puede / probablemente deba crear sus propios tipos de Exception que contienen toda la información que necesita para presentar todos los datos que necesita para el usuario.

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 lo haría un seguimiento de stack!

Digo casi siempre porque hay casos (como en IDE) en los que puedes considerar a tus usuarios lo suficientemente competentes desde el punto de vista técnico como para observar los rastros de stack; de hecho, en este caso probablemente lo prefieran a un mensaje de error “simplificado”.

Sin embargo, personalmente creo que los rastros de stack siempre deben registrarse en algún lugar al que el usuario pueda acceder para que si se quejan de que “el progtwig no está funcionando” pueda ver exactamente qué sucedió si le envían ese archivo.

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.

Yo argumentaría que nunca debería mostrar 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.