¿Qué estilo usas para los mensajes de excepción?

Question

Al escribir el código que arroja la excepción que pregunté sobre here, llegué al final de mi mensaje y me detuve ante la puntuación. ¡Me di cuenta de que casi todos los mensajes de excepción que he lanzado probablemente tienen! algun lado.

throw new InvalidOperationException("I'm not configured correctly!"); 
throw new ArgumentNullException("You passed a null!"); 
throw new StupidUserException("You can't divide by 0! What the hell were you THINKING??? DUMMY!!!!!"); 

¿Qué tono toma al escribir mensajes de excepción? Al revisar los registros, ¿encuentra que cierto estilo de mensaje realmente ayuda más que otro?

Answer 1

Un tono de conversación en los mensajes del sistema hace que el software parezca poco profesional y descuidado. Los puntos de exclamación, los insultos y la jerga realmente no tienen cabida en los mensajes de excepción pulidos.

Además, tiendo a utilizar diferentes estilos en Java para las excepciones de tiempo de ejecución y las excepciones marcadas, ya que las excepciones de tiempo de ejecución están dirigidas al programador que cometió el error. Dado que las excepciones de tiempo de ejecución pueden mostrarse a los usuarios finales, todavía "lo mantengo limpio", pero pueden ser un poco más escuetos y crípticos. Los mensajes de excepción controlados deberían ser más útiles, ya que es posible que el usuario solucione el problema si lo describe (por ejemplo, archivo no encontrado, disco lleno, sin ruta al host, etc.).

Una cosa que es muy útil, en ausencia de un campo específico en la excepción de la información, son los datos infractor:

throw new IndexOutOfBoundsException("offset < 0: " + off); 

Answer 2

Asumir la responsabilidad, incluso cuando realmente fue culpa del usuario, es la mejor opción que he visto.

Las cosas en la línea de "No puedo encontrar el archivo que deseaba, ¿podría verificar si lo tengo correctamente?" o "Algo salió mal. No sé qué, pero la única forma en que puedo solucionarlo es parándome. Por favor, reiníciame".

Answer 3

Solo se el hecho. Incluya toda la información que probablemente necesitará cuando depure, pero no más que eso.

La única vez que incluiría un signo de exclamación en un mensaje de excepción es si indica que algo realmente extraño sucedió. La mayoría de los errores no son realmente extraños, solo el producto de un entorno incorrecto, error del usuario o un error de programación simple.

Answer 4

Intento reflejar el tono, la gramática y el estilo de puntuación del marco sobre el que estoy codificando. Nunca se sabe cuándo uno de estos mensajes podría llegar a un cliente o usuario, por lo que mantengo todo lo que es profesional, sin prejuicios y lo suficientemente específico para la solución de problemas, sin ser tan específico como para revelar cualquier problema de seguridad en el código.

Evito los signos de admiración en todas las cadenas (IU y excepción) como la peste, excepto (ocasionalmente) en mis pruebas unitarias.

Answer 5

Información concisa, detallada y poco redundante (es decir, ArgumentNullException obviamente implicaba un nulo).

Pero aquí está el mejor que he leído por un tiempo, primera respuesta al this.

Answer 6

No usaría demasiado el signo de admiración. Expresan demasiado, piensan en el hecho de que "¡No hay disco en el disco!" se puede leer como "No hay disco en la unidad, usuario loco". ;)

Creo que es aconsejable lanzar excepciones que contengan texto internacionalizado. Nunca se sabe quién usará su código, detectará su excepción y mostrará el texto al usuario. por lo que sería:

throw new MagicalException(getText("magical.exception.text")); 

también recomiendo envolviendo la excepción subyacente (si tiene uno) cuando tirarlo. Realmente ayuda a la depuración.

No crea que el usuario no verá las excepciones de tiempo de ejecución. Si está iniciando sesión en un archivo adjunto, un usuario curioso podría simplemente abrir el registro y echar un vistazo a sus secretos sucios.

Answer 7

tiendo a trabajar mis mensajes de excepción en los propios excepción. P.ej. un file_not_found debería decir "archivo no encontrado". Los datos específicos solo deberían incluirse si el usuario no puede resolverlos; en este caso, el usuario conoce el nombre del archivo, por lo que no agrego esa información. El formateo se puede realizar por cualquier salida de la información si es necesario, por lo que trato de hacer que sean tan amigables con el reformateo como sea posible.

Answer 8

cortés, escueto, simple, específico. A menudo, incluir los valores de estado en el mensaje es útil.

Answer 9

puedo encontrar los mensajes más votos proporcionan:

• un formato coherente que hace que sea fácil de entender lo que le dicen.
• A marca de tiempo, para que pueda hacerse una idea de la dinámica de su programa.
• A resumen en pocas palabras del error. Si proporciona soporte técnico, agregue un código de error para una identificación rápida.
• Un explicación de lo que salió mal, diferenciar entre una entrada de usuario no válido y un error de codificación .
• información detallada, incluyendo la línea de código o valores involucrado .

Y lo más importante:

• le dicen al usuario cómo solucionar el problema.

Ejemplo:

Error 203 (Timeout) in commit.c line 42: 
Unable to save salary data for user 'Linus' to database at '10.10.1.21' 
after 1500ms. Verify database address and login credentials.

Una de las lecciones más difíciles de aprender es que sus usuarios son mucho menos interesado en los detalles internos de su código de lo que son en conseguir realizar su trabajo. Haz que sea tan fácil como sea posible para ellos hacer su trabajo, y le has agregado un enorme valor a tu software.