¿Cuánta información sobre un error debe mostrarse al usuario?

Las aplicaciones siempre pueden arrojar errores. Si se produce un error de este tipo, se debe notificar al usuario, porque lo que le pidió a la aplicación no ha tenido éxito.

Sin embargo, ¿cuánta información se le debe dar al usuario? Creo que la mayoría de nosotros estamos de acuerdo en no mostrar un seguimiento de la pila ( ¿Debería haber un seguimiento de la pila en el mensaje de error presentado al usuario? ), Pero no puedo encontrar una pregunta sobre el resto del contenido del error o qué mostrarle al usuario.

Por ejemplo, un idioma que admite excepciones (.net, java) tiene el tipo de excepción para compartir, dónde se produjo la excepción, y un mensaje un tanto clarificador para acompañar la excepción. ¿Debería esto también estar oculto para el usuario? ¿O deberíamos mostrar esto de todos modos? ¿O deberíamos mostrar un mensaje genérico? ¿o deberíamos mostrar uno de varios mensajes en función de cuál es la excepción subyacente?

Qué mostrar al usuario. ¿Debería esto también estar oculto para el usuario?

Le muestra al usuario lo que es accionable para ellos.

Por ejemplo, si tiene un error causado por alguna excepción de puntero nulo y más error que error de usuario, no desea una explicación completa porque no pueden hacer nada diferente.

¿O deberíamos mostrar esto de todos modos? ¿O deberíamos mostrar un mensaje genérico?

Mostrar la excepción como el contenido del mensaje de error primario no tiene sentido para la mayoría de los usuarios . Quizás si su base de usuarios objetivo es desarrolladores, podría mostrar la información como el error completo todo el tiempo (tal vez tenga una aplicación interna para pruebas automatizadas). Pero, en general, los usuarios no pueden hacer nada diferente incluso con ese conocimiento.

¿deberíamos mostrar uno de varios mensajes en función de cuál es la excepción subyacente?

La mejor estrategia es hacer lo siguiente:

• Interprete el error en texto que sea significativo para el usuario.
  • Parte de esto es "¿qué puede hacer el usuario de manera diferente?"
  • Si no pueden hacer nada diferente, diga algo como "se ha producido un error inesperado".
• Agregue una descripción de error detallada "opcional"
• Permitir a los usuarios enviar el informe de errores (o hacerlo automáticamente, según la base de usuarios)

Ejemplo

1. Muestra "esto es lo que sucedió" (error inesperado)
2. Le dice al usuario qué hacer (reabrir correo, incluso incluye un acceso directo para hacerlo)
3. También tiene "ver detalles" si alguien siente curiosidad por ver el error técnico completo
4. Proporciona notificación de que se archiva un informe de error (ver abajo)

Tenga en cuenta que, en algunos casos, es posible que desee que el informe de errores sea manual o automático.

Depende de quién sea el usuario y qué puede hacer con la información.

En general, trate de mostrarles solo información útil sobre cosas que puedan resolver por sí mismos. Una traza de 40 líneas con un error de expresión regular en la parte superior no es muy útil. Mucho mejor sería un mensaje que diga Fecha debe estar formateado como "aaaa-mm-dd" . Cualquier otra cosa, y el usuario puede no saber cómo responder al error, y luego puede que no quiera usar su aplicación, por temor a que cause más errores crípticos y aterradores (y sí, los usuarios no técnicos a veces se asustan por la pila rastros). Y eso podría ser malo para los negocios.

Para las aplicaciones internas utilizadas por otros desarrolladores, estoy un poco más relajado acerca de mostrar un seguimiento de pila, además de algo más útil , porque sé que el usuario puede manejar ver un seguimiento de pila y probablemente sepa qué hacer al respecto.

Para los usuarios no técnicos, la única vez que creo que estaría bien mostrarles un seguimiento de la pila es en una situación de error crítico donde lo necesitan para resolver el problema, y ​​se les pide que copien y peguen el seguimiento de la pila y lo envíen para usted, aunque realmente una forma mucho mejor de hacerlo es pedirles que envíen un archivo de registro, o mejor aún, que la aplicación envíe un archivo de registro al desarrollador, después de pedirle al usuario permiso para compartir el archivo.

Los mensajes a los usuarios deben tratarse de la misma manera que crear una nueva excepción para lanzar: usted proporciona la información que necesitarán para decidir qué hacer.

Por supuesto, esto dependerá de su aplicación y base de usuarios, pero debe ser su director rector; su intención debe ser proporcionar la información necesaria para que la "persona que llama" determine qué puede hacer, si es que puede hacer algo, para realizar con éxito la acción deseada. . Si es algo simple como un error de acceso a un archivo, le da una ruta de acceso al archivo y el mensaje de que no puede acceder a él. Si se trata de una excepción de puntero nulo, solo envíe un mensaje de error genérico.

Por supuesto, habrá más mensajes de "incapaz de realizar la acción deseada" que mensajes que el usuario pueda corregir, pero así es la vida: la mayoría de las excepciones se deben a que cometimos un error, no porque el usuario configuró el entorno incorrectamente.

Este es un tema común:

¿Cómo puede ayudar a los analfabetos desinformados / informáticos al mismo tiempo que muestra información que pueden usar los usuarios más avanzados, como programadores, desarrolladores, evaluadores, etc.

¡Creo que la respuesta es que haces las dos cosas!

Sin embargo, el orden es importante y le recomiendo que tenga:

• Que pasó.
• Qué hacer ahora
• Detalles técnicos

Detalles técnicos es la parte que tiene información para pedidos avanzados o para usuarios habituales cuando se informa un problema

Lo que quieres mostrar depende de lo avergonzado que estés por arruinarlo.

El punto es obtener los detalles de la falla al soporte técnico de la manera más rápida y fluida posible. Eso puede significar que envía el archivo de registro, incluido el seguimiento de la pila del error de terminación, de vuelta a casa automáticamente o le pide al usuario que haga clic en un botón que iniciará la transferencia. Tal vez a través de una memoria USB si no hay conexión a Internet.

Me gusta la razón detrás de la respuesta aceptada, pero debo discrepar respetuosamente al menos con mi interpretación de limitar la información a lo que es "procesable" . Quiero saber un poco más que eso como usuario que "error inesperado" .

Y admito que soy un poco experto en informática y tengo ese sesgo, pero no creo que esta sea una visión particularmente sesgada. Porque puedo hacer todo lo posible para eliminar ese sesgo aplicando esta mentalidad a dominios para los que tengo poca experiencia, como la aviación.

Si bien sé poco sobre la aviación, digamos que mi vuelo se retrasa o cancela y lo único que el personal me dice es: "Tuvimos un error inesperado. Espere 3 horas para un vuelo posterior". Al menos me encontrará un poco más de un cliente descontento en esos casos porque, aunque en realidad no afecta mi curso de acción de ninguna manera, solo quiero saber un poco más sobre por qué estoy siendo incomodado de esta manera como cliente que paga.

Si simplemente dijeron: "Estamos experimentando un clima turbulento", o "Tuvimos una emergencia médica en nuestro vuelo anterior", o un mal funcionamiento del equipo o lo que sea, eso es suficiente para que comparta mucho más que un "error inesperado" y estar un poco más contento sentado y esperando 3 horas para el próximo vuelo. En realidad, incluso podría preferir un poco de tecnobabble que se me pasa por la cabeza a un "error inesperado" como, "Está bien, las palabras que salen de tu boca van a mi oído pero no llegan al procesador central. Pero ahora entiendo que hay algún tipo de problema allí y voy a tomar un café y sentarme allí. ¡Espero que resuelvan ese problema con esa cosa increíble! "

Y a menudo en términos de manejo de excepciones, creo que generalmente tiene suficiente información básica sobre lo que sucedió en el catchsitio, incluso si desea ocultar los detalles más técnicos de la excepción, como:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

Y eso ni siquiera muestra lo que podría ser la información muy técnica adjunta a la excepción, pero al menos nos dice mucho más que un "error inesperado". Al menos proporciona un "qué / dónde / cuándo" contextual, incluso si no dice "por qué / cómo". Creo que al menos el deseo de este nivel básico de información no está particularmente sesgado por mi conocimiento de la computadora.

El resto probablemente sea muy específico para sus clientes y necesidades particulares. Pero mi atractivo es al menos para algo un poco más que "error inesperado".