¿Qué estilo utilizas para los mensajes de excepción? [cerrado]

StackOverflow https://stackoverflow.com/questions/259887

Pregunta

Al escribir el código que arroja la excepción, pregunté sobre aquí , 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 un! en algún lugar. 

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?

¿Fue útil?

Solución

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

Además, tiendo a usar diferentes estilos en Java para excepciones de tiempo de ejecución y excepciones marcadas, ya que las excepciones de tiempo de ejecución se dirigen 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 concisos y crípticos. Los mensajes de excepción marcados deberían ser más útiles, ya que puede ser que el usuario pueda solucionar el problema si lo describe (por ejemplo, archivo no encontrado, disco lleno, sin ruta al host, etc.).

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

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

Otros consejos

Solo sea una cuestión de hecho. Incluya toda la información que probablemente necesite al depurar, 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 ha sucedido algo realmente extraño. La mayoría de los errores no son realmente extraños, solo el producto de un entorno incorrecto, un error del usuario o un simple error de programación.

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

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

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

Cosas en la línea de "No puedo encontrar el archivo que buscabas, ¿comprobarías si lo tengo correctamente?" o '' Algo salió mal. No sé qué, pero la única forma en que puedo arreglarlo es deteniéndome. Por favor, reiníciame. & Quot;

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

Pero aquí está lo mejor que he leído por un tiempo, primero responda a esto .

No usaría demasiado los signos de exclamación. Expresan demasiado, piense en el hecho de que "¡No hay disco en la unidad!" puede leerse 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. Entonces eso sería: 

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

También recomiendo envolver la excepción subyacente (si tiene una) al lanzarla. Realmente ayuda a la depuración.

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

Creo que los mensajes más útiles proporcionan:

  • Un formato coherente que facilita la comprensión de lo que le están diciendo.
  • Una marca de tiempo , para que pueda tener una idea de la dinámica de su programa.
  • Un breve resumen del error. Si proporciona asistencia técnica, agregue un código de error para una identificación rápida.
  • Una explicación de lo que salió mal, diferenciando entre una entrada de usuario no válida y un error de codificación.
  • Información detallada , incluida la línea de código o valores involucrados.

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 están mucho menos interesados ??en las partes internas de su código que en hacer su trabajo. Haga que sea lo más fácil posible para ellos hacer sus trabajos, y ha agregado un gran valor a su software.

Tiendo a trabajar mis mensajes de excepción en la excepción ellos mismos. P.ej. un archivo_no_encontrado debería decir "archivo no encontrado". Los datos específicos solo deben incluirse si el usuario no puede resolverlos; en este caso, el usuario conoce el nombre del archivo, así que no agrego esos datos. El formateo se puede hacer con cualquier salida de la información si es necesario, así que trato de hacerlos lo más amigables posible para formatearlos.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top