¿Cuán detallados deberían ser los mensajes de error?

Question

Me preguntaba cuál era el consenso general sobre los mensajes de error. ¿Qué tan detallados deben ser?

He trabajado en proyectos donde había un mensaje de error diferente para ingresar un número que era demasiado grande, demasiado pequeño, tenía un decimal, era una cadena, etc. Eso fue bastante bueno para el usuario ya que sabía exactamente dónde Las cosas salieron mal, pero el código de manejo de errores comenzó a rivalizar con la lógica de negocios real en tamaño y comenzó a desarrollar algunos de sus propios errores.

En el otro lado, he trabajado en un proyecto en el que obtendrías errores muy genéricos, como

  

COMPILA LA RAZON 3

Lo que no hace falta decir era casi completamente inútil, ya que la razón 3 resultó ser un error de enlace.

Entonces, ¿dónde está el término medio? ¿Cómo puedo saber si he agregado suficientes mensajes de error descriptivos? ¿Cómo puedo saber si el usuario podrá entender dónde se equivocó?

Answer 1

Hay dos posibles audiencias de destino para un mensaje de error, el usuario y el desarrollador.

Generalmente, uno debe tener el mensaje dirigido al usuario.

o cuál es la causa del problema.
 ¿Por qué el programa no puede solucionar el problema?  o lo que el usuario puede hacer para solucionar el problema.
 o cómo reportar el problema.

Si se debe informar el problema, el informe debe incluir la mayor información posible sobre el contexto del programa.

o nombre del módulo
 o nombre de la función
 o numero de linea
 o variables de interés en el área general del problema.  o tal vez incluso un volcado de núcleo.

Dirígete a la audiencia correcta.

Answer 2

Debe comunicar qué sucedió y cuáles son las opciones del usuario, en la menor cantidad de palabras posible. Cuanto más largo sea el mensaje de error, menor será la probabilidad de que el usuario lo lea. De la misma manera, los mensajes de error cortos son crípticos e inútiles. Hay un punto dulce en términos de longitud, y es diferente para cada situación.

Demasiado corto:

  

Entrada no válida.

Demasiado largo:

  

Introduzca una dirección IP correctamente formateada, como 192.168.0.1. Una dirección IP es un número que se utiliza para identificar su computadora en una red.

A la derecha:

  

Introduzca una dirección IP válida.

En lo que se refiere al aumento de código, si un pequeño código adicional evitará que un usuario llame al servicio de asistencia o se deje frustrado, es una buena inversión.

Answer 3

Hay dos tipos de mensajes de error: los que verá el usuario y los que verá el programador.

" ¿Cómo puedo saber si el usuario podrá entender dónde se equivocó? " Asumo que esos mensajes solo serán vistos por el usuario, y no muy técnicos, y COMPILE FAILED RASON 3 no es un mensaje de error típico de usuario final. Es algo que el programador verá (el usuario generalmente no compila las cosas).

Entonces, si es el usuario el que lo verá:

1. Proporcione un breve " Este es un mensaje de error " (" ¡Ops! ¡Algo salió mal! " ;, etc.)
2. Proporcione una pequeña descripción genérica del error (" El sitio al que intenta conectarse parece no estar disponible " / " Parece que no tiene los permisos suficientes para realizar la tarea XYZ " / etc.)
3. Añade un " Detalles > > " botón, en caso de que su usuario entienda bien las computadoras, incluida información detallada (seguimiento de la pila de excepciones, código de error, etc.)

Finalmente, proporcione algunos comandos simples y comprensibles para el usuario (" Inténtelo de nuevo " ;, " Cancel " ;, etc.)

Answer 4

La verdadera pregunta sobre los mensajes de error es si deberían mostrarse. Se presentan muchos mensajes de error a un usuario, pero NO HAY NINGUNA MANERA para corregirlos.

Siempre que haya una manera de corregir el error, proporcione suficiente información al usuario que le permita corregirlo por su cuenta. Si no son capaces de corregirlo por su cuenta, ¿hay alguna razón para decirles la razón técnica del accidente? No, simplemente inicie sesión en un archivo para solucionar el problema más adelante.

Answer 5

Tan detallados como deben ser;)

Sé que suena como una respuesta inteligente, pero gran parte de esto depende de su público objetivo y del tipo de error. Para los errores causados ??por una entrada de usuario no válida, puede mostrarles lo que constituye una entrada válida. Para los errores que el usuario no puede controlar, un genérico " estamos trabajando en ello " tipo de mensaje podría hacer.

También estoy de acuerdo con los comentarios de Jon B sobre la longitud.

Answer 6

Los mensajes de error deben ser detallados, pero claros. Esto se puede lograr combinando mensajes de error de múltiples niveles:

Failed to save the image
Permission denied: /foo.jpg

Aquí tenemos dos niveles. Puede haber más. Primero contamos el panorama general y luego contamos los detalles. El orden es tal que primero entendemos la parte que comprende la mayoría y luego la parte que menos gente entiende, pero ambas pueden ser visibles.

Además, podría haber una sugerencia de corrección.

Answer 7

Me equivocaría por más detalles, pero creo que respondiste tu propia pregunta. Para evitar la expansión del código, proporcione información útil en el código / mensaje de error, pero puede dar más detalles en la documentación tal vez o con archivos de ayuda o preguntas frecuentes.

tener muy poca información es peor en mi opinión.

Si está utilizando un idioma con una introspección enriquecida u otras capacidades, sería útil un registro con la línea que falló en una verificación. Luego, el usuario puede reenviarse al soporte técnico o, de lo contrario, obtener información detallada, y no se trata de un código adicional, sino de su propio código para proporcionar información.