¿Cuáles son los problemas del desarrollador con mensajes de error útiles? [cerrado]

29

Sigue sorprendiéndome que, en la actualidad, los productos que tienen años de uso en su haber, construidos por equipos de profesionales, aún hoy en día, no brindan mensajes de error útiles al usuario. En algunos casos, la adición de solo una pequeña información adicional podría ahorrarle al usuario horas de problemas.

Un programa que genera un error, lo generó por una razón. Tiene todo a su disposición para informar al usuario tanto como pueda, por qué algo falló. Y, sin embargo, parece que proporcionar información para ayudar al usuario es de baja prioridad. Creo que esto es un gran fracaso.

Un ejemplo es de SQL Server. Cuando intenta restaurar una base de datos que está en uso, con bastante razón no le permitirá. SQL Server sabe qué procesos y aplicaciones están accediendo a él. ¿Por qué no puede incluir información sobre los procesos que utilizan la base de datos? Sé que no todos pasan un Applicatio_Nameatributo en su cadena de conexión, pero incluso una pista sobre la máquina en cuestión podría ser útil.

Otro candidato, también SQL Server (y mySQL) es el encantador string or binary data would be truncatedmensaje de error y equivalentes. Muchas veces, una simple lectura de la declaración SQL que se generó y la tabla muestra qué columna es la culpable. Este no es siempre el caso, y si el motor de la base de datos detectó el error, ¿por qué no puede ahorrarnos ese tiempo y simplemente nos dice qué maldita columna era? En este ejemplo, podría argumentar que puede haber un impacto en el rendimiento al verificarlo y que esto impediría al escritor. Bien, lo compraré. ¿Qué tal si una vez que el motor de la base de datos sabe que hay un error, realiza una comparación rápida después del hecho, entre los valores que iban a almacenarse y las longitudes de las columnas? Luego, muéstralo al usuario.

Los horribles adaptadores de tabla de ASP.NET también son culpables. Las consultas se pueden ejecutar y se puede enviar un mensaje de error que indica que se está violando una restricción en alguna parte. Gracias por eso. Es hora de comparar mi modelo de datos con la base de datos, porque los desarrolladores son demasiado vagos para proporcionar incluso un número de fila o datos de ejemplo. (Para el registro, nunca usaría este método de acceso a datos por elección , ¡es solo un proyecto que heredé!).

Cada vez que lanzo una excepción de mi código C # o C ++, proporciono todo lo que tengo a mano para el usuario. Se tomó la decisión de tirarlo, de modo que cuanta más información pueda brindar, mejor. ¿Por qué mi función arrojó una excepción? ¿Qué se pasó y qué se esperaba? Me lleva un poco más de tiempo poner algo significativo en el cuerpo de un mensaje de excepción. Demonios, no hace más que ayudarme mientras me desarrollo, porque sé que mi código arroja cosas que son significativas.

Se podría argumentar que los mensajes de excepción complicados no deberían mostrarse al usuario. Si bien no estoy de acuerdo con eso, es un argumento que se puede apaciguar fácilmente al tener un nivel de verbosidad diferente dependiendo de su construcción. Incluso entonces, los usuarios de ASP.NET y SQL Server no son sus usuarios típicos, y preferirían algo lleno de verbosidad e información deliciosa porque pueden rastrear sus problemas más rápido.

¿Por qué los desarrolladores piensan que está bien, en estos tiempos, proporcionar la mínima cantidad de información cuando ocurre un error?

Es 2011 chicos, vienen en .

design exceptions error-messages Jugo De Moo
fuente
11
Wow, eso es una queja.
George Marian
3
@ George, ¿puedes decir que acabo de pasar mucho tiempo rastreando algo que realmente podría haberse resuelto más rápido si hubiera un error adecuado? :)
Moo-Juice
44
Sugiero respiraciones profundas, tal vez algo de yoga y meditación. :) (Dicho esto, sé exactamente cómo te sientes.)
George Marian
2
+1 - "la cadena o los datos binarios se truncarían" siempre me vuelve loco.
k25

Respuestas:

22

Si bien hay muchos ejemplos de mensajes de error incorrectos que simplemente no deberían existir, debe tener en cuenta que no siempre es posible proporcionar la información que le gustaría ver.

También existe la preocupación de exponer demasiada información, lo que puede llevar a los desarrolladores a cometer errores por precaución. (Te prometo que el juego de palabras no fue intencionado, pero no lo eliminaré ahora que lo noté).

A veces, también existe el hecho de que un mensaje de error complejo es inútil para el usuario final. Ponerse del lado de la sobrecarga de información no es necesariamente un buen enfoque para los mensajes de error. (Eso puede ser mejor guardado para el registro).

George Marian
fuente
+1 Ni siquiera pensé en el aspecto de sobrecarga de información.
Ryan Hayes
Expliqué en mi publicación que puedo entender por qué algunos sienten que la verbosidad para un usuario final podría ser inútil para ellos. Pero, ¿está diciendo que los usuarios finales de una API (adaptadores de ASP.NET) o un motor de base de datos (SQL-Server) no quieren errores detallados? ¿Algo que nos ahorre potencialmente horas de tiempo perdido? Por cierto, me gustó el juego de palabras :)
Moo-Juice
1
@George, también con respecto a la sobrecarga de información y su utilidad para el usuario final, nuevamente puedo ver un caso para no lanzar un seguimiento completo de la pila al usuario de un procesador de textos, para que no tengan un momento de pantalones marrones y creo que han eliminado internet. Sin embargo, ha proporcionado una excelente alternativa con información compleja en el archivo de registro. Todo lo que ese mensaje debe hacer ahora es agregar For further information, see log20111701.txt. Este sería un paso en la dirección correcta.
Moo-Juice
2
@moo En última instancia, lo que digo es que es fácil criticar. (Lo sé, lo hago a menudo.) Sin embargo, trato de tener en cuenta que no es necesariamente fácil determinar cuánta información debe incluir en un mensaje de error. Hay muchas ocasiones en las que he tenido que retroceder y generar información más detallada de la que originalmente anticipé durante la depuración. Además, hay muchas ocasiones en que un mensaje de error no fue tan útil como había previsto al crearlo.
George Marian
1
@moo El quid de la cuestión es que no siempre es obvio cuánta información es útil. Los ejemplos que proporciona parecen bastante obvios. Sin embargo, no es fácil extender eso al caso general.
George Marian
21

Los desarrolladores no son las personas adecuadas para escribir mensajes de error.

Ven la aplicación desde el ángulo equivocado. Son extremadamente conscientes de lo que salió mal dentro del código, pero a menudo no se están acercando al software desde el punto de vista de intentar lograr algo. Como resultado, la información importante para el desarrollador no es necesariamente información importante para el usuario.

David Thornley
fuente
+1 Para muchos de los errores de tipo Framework / API, parte del problema es que el desarrollador de la biblioteca no puede conocer el contexto. Dicho esto, OP parece preocupado principalmente por el tipo de mensajes de error "algo está mal, pero no voy a decirte dónde aunque sé". Supongo que es seguridad, ¿verdad?
MIA
8

La vista caritativa:

  • El desarrollador trabajó de cerca con el código y luchó por comprender a alguien que no entendía cómo funcionaba. Como resultado, piensan que los mensajes de error están bien, simplemente no tienen un buen marco de referencia para juzgarlos.

  • Los mensajes de error inteligentes son realmente difíciles de hacer. No solo debe escribirlos, sino que debe resolver todo lo que pueda salir mal, evaluar la probabilidad y proporcionar información útil (que casi con certeza varía según el contexto) a la persona que lee el mensaje para que pueda corregirlo.

  • Para la mayoría de las aplicaciones, es difícil hacer un buen caso para el momento de hacer este tipo de cosas, así como al próximo desarrollador realmente le gustaría porque los errores no ocurren con tanta frecuencia. Además, si tuviera ese tiempo extra, ¿no debería pasarlo deteniendo los errores en lugar de informar sobre ellos?

La visión poco caritativa:

  • Los mensajes de error y el manejo de errores son aburridos, hay cosas mucho más interesantes en las que trabajar y mi jefe está de espaldas sobre lo siguiente. Entiendo este código, estaré bien, el próximo tipo lo resolverá al final y saldré de aquí para entonces, así que no es mi problema.

La realidad probablemente esté en algún punto intermedio, aunque mi experiencia en realidad me dice que es mucho más la primera que la última, básicamente es bastante difícil y requiere una gran cantidad de esfuerzo para lidiar con algo que probablemente no sucederá.

Jon Hopkins
fuente
Entiendo de dónde vienes en muchos casos de usuarios finales. Sin embargo, los casos que describí en mi publicación original pueden ocurrir con frecuencia al escribir código en bases de datos. Con respecto a las aplicaciones del usuario final, como un procesador de texto o un juego de computadora, los errores generalmente no deberían ocurrir a menos que ocurra algo malo , e incluso entonces el error podría no significar nada para el usuario final ( Process Handle Raped By Spawned Injector, Quitting SYstem.... usuario: "wtf did I do?`). Pero en el caso de SQL Server / ASP.NET, creo que se podría haber hecho más esfuerzo :)
Moo-Juice
@ Moo-Juice: creo que todo se reduce a todo lo de "los mensajes de error son difíciles". Debajo del capó, lo que en realidad se arroja a la base de datos una vez que el optimizador lo ha hecho, solo tiene un parecido pasajero con lo que le arrojaste. Identificar el error es una cosa, rastrear lo que sucedió con lo que pasó es otra completamente y absolutamente no es trivial.
Jon Hopkins
Algunos casos pueden no ser triviales. Tengo un simple código en algún lugar que detecta el string/binary dataerror que extrae toda la información de la columna de dicha tabla, examina los valores anteriores y muestra qué columnas habrían estado en violación. Esto fue trivial. Tal vez me estoy quejando demasiado porque mis ejemplos de casos son triviales, pero entiendo totalmente que este no es siempre el caso. La forma en que detenemos los inyectores generados por los procesos de violación puede ser difícil :)
Moo-Juice
6

Desafortunadamente, los mensajes de error más útiles le cuestan tiempo al desarrollador, lo que equivale al dinero de la empresa. Los productos son lo suficientemente caros como para construirlos. Sí, sería increíble tener mensajes de error más útiles, y estoy de acuerdo en que deberían incluirse otros más útiles. Sin embargo, es solo un hecho de la vida que cuando tienes una fecha límite y hay dinero en juego, tienes que cortar algo. Los "mensajes de error más bonitos", como los administradores pueden verlo, probablemente sean lo primero que se vaya.

Ryan Hayes
fuente
Ah, sí, buen punto. Esa preocupación siempre presente de costo.
George Marian
Puedo conceder una perspectiva de costos (y maldición, eso no significa que me tenga que gustar ). No puedo hablar desde el punto de vista de los desarrolladores de SQL Server o ASP.NET, pero sí sé que no hace falta que tanto esfuerzo adicional para proporcionar un nombre de columna. Admito que, por mi simple ejemplo, podría resolverse en una hora. Luego están los otros 1000 errores que podrían generarse. Pero al menos podrían comenzar con los comunes :)
Moo-Juice
por supuesto, no conozco los aspectos internos del servidor SQL, pero en general, la mayoría de las veces no tiene esa información a mano en el momento en que se detecta la situación de error. Una formulación como "cadena o datos binarios" muestra claramente que en el sitio del error, ni siquiera está claro si el valor truncado era una cadena o un número ...
Ichthyo
En algún nivel, esto puede ser válido, pero el mismo problema incluso surge en simples scripts en perl donde simplemente agrega $! al mensaje de error sería inmensamente útil. Es más barato (en términos del tiempo del desarrollador) escribir 'die "$ path: $!"' Que escribir el 'dado "completamente inútil" No se pudo abrir $ path "'
William Pursell
6

Estoy de acuerdo en que los mensajes de error deben ser lo más específicos posible.

Una razón para los mensajes de error genéricos es probablemente el uso de códigos de error. Al usar excepciones, puede pasar todo lo que necesita en el mensaje de error. Usando códigos de retorno no hay espacio para codificar un nombre de columna. Quizás el error es manejado por una función genérica que no conoce el contexto y simplemente traduce el código de error a una cadena.

ThomasW
fuente
es aún peor: si bien puede desencadenar errores en puntos muy específicos, para manejar los errores, se ve obligado a incluir varias posibilidades en una clase de situaciones y manejarlas con una sola recuperación. Este acto de generalización a menudo te obliga a descartar aún más la escasa información de contexto adicional.
Ichthyo
por cierto ... este mecanismo conduce a toda una clase de mensajes de error graciosos - en la línea de "Falla grave -567 en el módulo enano678: No se detectó ningún error"
Ichthyo
4
  • A veces, demasiada información puede ser un riesgo de seguridad; no sabes quién está leyendo el mensaje de error
  • A veces, la operación que arrojó la excepción es tan compleja que es imposible obtener un mensaje significativo sin efectos negativos en la velocidad / complejidad del código
StuperUser
fuente
Respondí tu primer punto permitiendo un cambio de verbosidad a las excepciones lanzadas en tu código. Su segundo punto es discutible dado que en este punto, se ha producido un error y la velocidad ya no es un factor decisivo (en mi humilde opinión). Y si producir un mensaje de error detallado requiere un impacto en el rendimiento ANTES de lanzar la excepción, acepto. Mueva ese código para DESPUÉS de que se haya lanzado la excepción. No veo ninguno de estos puntos como un argumento válido contra los mensajes de error adecuados :)
Moo-Juice
Es cierto, supongo que puede buscar la información una vez que ha sucedido algo en lugar de realizar un seguimiento de lo que pueda necesitar. Sin embargo, si estás en bucles anidados, capturar los índices / índices puede ser problemático.
StuperUser
-1 para el primer punto con el que no estoy de acuerdo, +1 para el segundo punto.
Jon Hopkins
1
@jon Contraste un mensaje de error genérico para errores de inicio de sesión versus mensajes de error más específicos que realmente le dicen qué salió mal. por ejemplo, "No pudimos encontrar esa combinación de nombre de usuario / contraseña" versus "Ingresó una contraseña incorrecta" / "Ese nombre de usuario no existe" Parece recordar una vulnerabilidad en ASP.NET donde el mensaje de error fue realmente útil para descifrar claves de cifrado.
George Marian
@George: estoy de acuerdo con ese ejemplo, pero no creo que esté muy extendido. Una vez que se le ha otorgado acceso a una aplicación, desaparece un cierto nivel de riesgo, ya que puede asumir que la persona está (a) autorizada y (b) podría obtener la mayor parte de lo que necesita de la aplicación real.
Jon Hopkins
3

Como aviso general, debe considerar que cualquier error o situación excepcional es, exactamente eso: excepcional. Se cruza el procedimiento planificado y diseñado. Es incompatible con la forma en que las cosas se planearon para trabajar. Si este no fuera el caso, entonces no habría necesidad de rescatar con un error abortar.

Los programadores estamos capacitados para cuidar la autoprotección de este procedimiento planificado. Por lo tanto, incluimos rutinariamente algunos controles de cordura para verificar nuestros supuestos. Cuando estos controles de cordura fallan, sabemos que el plan de alguna manera falló ...

Su demanda, que puede parecer sentido común desde la perspectiva del usuario, es imposible de cumplir si considera la realidad de cómo funciona dicho sistema. Solicita una declaración ordenada con información bien organizada y adecuada añadida. Además, incluso pide que esta presentación se realice de una manera que se ajuste al diseño general de la aplicación / manejo. Obviamente esta información existe en algún lugar del sistema. Obviamente, incluso existe allí de manera ordenada y bien organizada (esperemos que sí). PERO en el momento en que ocurre el error, nadie planeó poner esta información a disposición. Un error siempre es una pérdida parcial de control.Esta pérdida de control puede ocurrir en varios niveles. Podría ser que el sistema se comporte en tiempo de ejecución de manera diferente a lo planeado. Pero también podría ser que la implementación real resultó mucho más difícil y diferente en los detalles que se planificaron, y no hubo una disposición presupuestaria para manejar esta situación satisfactoriamente. Esto también es una pérdida parcial de control.

Para relacionar esto con el ejemplo concreto que dio: Si, en el momento del error, se conociera el nombre y el tipo de la columna de la tabla, y además la longitud del espacio requerido, entonces no habría ninguna razón para planteando un error, ¿no? Podríamos solucionar la situación y proceder según lo planeado. El hecho de que nos veamos obligados a generar un error nos muestra que las cosas se extraviaron. El hecho mismo de que estas informaciones no estén disponibles es la excepción .

Lo que estoy escribiendo aquí puede parecer evidente y simple sentido común. Pero en realidad es extremadamente difícil de entender. Intentamos constantemente entenderlo aplicando categorías morales , como debe haber un culpable, debe haber una persona mala y perezosa que no se preocupe por el usuario pobre, debe haber un hombre de negocios codicioso que haya hecho un cálculo económico. Todo esto está completamente fuera del punto.

La posibilidad de pérdida de control se debe al hecho de que estamos haciendo las cosas de manera planificada y ordenada .

Ichthyo
fuente
Tengo que estar en desacuerdo. Sabe que algo está mal (no puede realizar la operación). Saber que algo está mal indica un conocimiento de por qué está mal. Esta cadena es demasiado grande para esa columna (o una columna en esa tabla). Me podría decir, sin mucho trabajo. Es un maldito motor de base de datos empresarial. Se sabe . Pero no transmite esa información. Dado que el programador puede escribir una consulta para ejecutar después de que el hecho de descubrirlo muestre que el motor de la base de datos podría hacer lo mismo. Estas no son facetas indocumentadas secretas. Solo un mensaje de error horrible :)
Moo-Juice
je ... deberías basar tu argumento en la lógica, no en el pensamiento malicioso. ¿Desde cuándo una computadora sabe algo? Este no es el cine de Hollywood. Un programa es una configuración rígida y preestablecida, y cuando sus suposiciones se rompen, pierde el control. ¿Es realmente tan difícil de entender? Una computadora no entiende el programa, por lo que no puede entender cuándo va mal. Casi siempre, cuando se activa una comprobación de coherencia, la ejecución ya ha sido realizada por miles de declaraciones y nadie sabe qué datos ya se han dañado. Todo lo que puedes hacer es limitar el daño
Ichthyo
2

Trabajo como ingeniero de soporte para una empresa de software y, a menudo, vemos mensajes de error que son nuevos para nosotros. Con frecuencia, cuando remito estos a nuestro equipo de desarrollo, tienen que buscar el mensaje en la fuente de la aplicación.

Me parece que incluso si no se presentara a los usuarios, nos ahorraría mucho tiempo si el equipo de desarrollo agregara una nota a un documento o base de datos de índice de mensajes de error cada vez que agregaran uno nuevo, lo haría mucho más rápido para nosotros encontrar la causa de los problemas de los clientes y también ahorrarles tiempo ...

glenatron
fuente
1
lo siento, eso es poco práctico. Quién sería responsable de administrar ese documento de índice, de mantenerlo preciso. Como cualquier documentación escrita separada del código, estaría desactualizada y comenzaría a obtener una fuente de nuevos errores en el momento en que se escribe.
Ichthyo
Por el contrario, ese es el tipo de cosas que un script puede extraer del código fuente, si cada error tiene un número único, y la descripción de cada uno también estaba en el código, ya sea en forma de un comentario (especialmente formateado) o como un cuerda. Por lo tanto, el documento se generaría automáticamente con cada compilación. El mensaje extraído podría ser bastante más detallado que cualquier cosa que quisiera que el usuario final vea. ¡No es una mala idea!
Jeanne Pindar
no necesita un script para eso: muchos sistemas de tiempo de ejecución pueden registrar el número de línea o alguna información similar. Desafortunadamente, esto no ayuda con el problema original, porque de esta manera solo sabemos dónde se detectó una excepción, pero no sabemos qué salió mal . Descubrir esto último se llama depuración ; en la práctica, esta es una tarea más o menos tediosa y laboriosa realizada por humanos.
Ichthyo
Estoy con @Jeanne, lo suficientemente simple como para incorporarlo en el código o para tener un índice central en el código con el código de error y su interpretación. Una vez que sepa dónde se detectó una excepción, eso puede ser suficiente para decirle que hay un problema con el entorno en algún lugar en lugar de algo en el código que necesita ser perseguido.
glenatron
2

El problema que está viendo allí es en realidad uno de los efectos secundarios de la encapsulación adecuada y el ocultamiento de la información.

Los sistemas modernos son extremadamente complicados. Hay pocas posibilidades de que el desarrollador promedio pueda mantener, en su cabeza, un modelo mental de todo el sistema, desde la interfaz de usuario hasta el binario sin procesar, mientras codifica cualquier tarea en particular.

Entonces, mientras un desarrollador se sienta y codifica, digamos, el bit que restaura un archivo de base de datos, su modelo mental se llena por completo con los bits que rodean el acto de restaurar un archivo de base de datos. Necesita (y supongo que no he escrito este código) leer un archivo, verificar propiedades, leer versiones, hacer una copia de seguridad de los datos existentes, elegir una estrategia de fusión / sobrescritura, etc. Muy probablemente, incluso si hay un paso considerando la interfaz de usuario, está en la cadena de error que escribe en un controlador de excepciones. Algo como:

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

En este ejemplo, la información útil sobre la que está preguntando en términos de procesos que podrían estar usando el archivo, o incluso otros subprocesos en la base de datos, está completamente fuera de alcance (programáticamente). Puede haber cientos de clases que tratan con archivos DB; importar a esas clases información sobre cualquier otro proceso utilizando los archivos o la funcionalidad para acceder al sistema de archivos y observar los otros procesos en ejecución (suponiendo que esos procesos estén incluso en ESTA máquina) daría como resultado lo que se conoce como una abstracción con fugas ; Hay un costo directo en la productividad.

Así es como este tipo de errores pueden persistir en los días modernos. Obviamente, todos PODRÍAN ser reparados; pero en muchos casos, hay mucha más sobrecarga de lo que uno podría pensar (en este caso, por ejemplo, es posible que tenga que hacer que esta función atraviese la enumeración de conexiones de red y recursos compartidos para ver si una máquina remota está utilizando este archivo de base de datos para algunos razón) y el costo está lejos de ser trivial.

GWLlosa
fuente
@GWLlosa, esta es una gran respuesta y una que no había considerado. Dicho esto (y no puedo proporcionar un ejemplo de código completo aquí), cuando obtengo esa IOException, antes de lanzar mi GenericException, podría 1) Solicitar al ProcessesSubsistema una lista de procesos. 2) Pregunte a cada proceso qué base de datos están utilizando. 3) Haga coincidir el proceso con la base de datos asignada a la que estoy tratando de sobrescribir, 4) arroje una DatabaseInUse(dbName, processName, applicationNameexcepción. :)
Moo-Juice
1
Ciertamente posible; pero el código para hacer coincidir la base de datos con el proceso (especialmente a través de la red) puede ser complicado / lento / propenso a errores, lo que podría generar cierta frustración adicional ("¡Solo estoy tratando de restaurar lo local (* #% ^! % file !!!! POR QUÉ
ME IMPORTA
1
@ Moo-Juice: lo que propones suena bastante ingenuo. En un entorno multiproceso masivo, como una base de datos, no puede simplemente comunicarse con algún servicio global para obtener una lista de "todos xyz". Incluso para hablar con algún otro servicio en otro hilo, necesita un bloqueo, lo que podría llevar a un punto muerto en todo el sistema en el peor de los casos, podría corromper otros datos o al menos podría causar errores adicionales, que también debe manejar. ....
Ichthyo
1
Ese ejemplo es realmente muy instructivo: por lo general, en un controlador de captura de este tipo, ni siquiera se puede saber con certeza qué parte del bloque try falló (generalmente hay varias partes que podrían causar una IOException). Además de eso, es muy probable que en esa ubicación no pueda decir el nombre del archivo, no sea que pueda decir qué tabla lógica corresponde a este archivo.
Ichthyo
@Ichthyo, no te ofendas, pero no creo que sea ingenuo en absoluto. No le estoy pidiendo al motor de la base de datos que bloquee el sistema para decirme qué proceso todavía tiene un identificador para una base de datos. No le estoy pidiendo que detenga toda la empresa. Si necesita darme una respuesta simple, eso muestra un defecto de diseño fundamental del servidor de base de datos en primer lugar. Recuerde, se supone que está diseñado para devolver la información pertinente de la manera más rápida posible. Para hacerle la pregunta "¿quién?" realmente no debería ser tan ingenuo como dices :)
Moo-Juice
2

Mi favorito era (a finales de los años 70) el compilador Univac Fortran IV, cuando leía no dígitos, anunció fielmente

Se intentó la interpretación de datos sin sentido.

hombre sonriente
fuente
+1, ¡absolutamente fantástico! Es el tipo de error que hace que solo quieras rendirte e ir a criar gallinas en Fiji.
Moo-Juice
de hecho, este mensaje de error es 100% exacto: si desea un mensaje más amigable con más texto, necesita incorporar algunas conjeturas y heurísticas; de esta manera agrega la posibilidad de mensajes de error engañosos ..
Ichthyo
0

Creo que la mayoría de los mensajes de error son en realidad declaraciones de código de depuración / printf glorificadas (auto) orientadas al programador.

Escribir mensajes de error orientados al usuario significa saber quién es su usuario y anticipar lo que querrá saber. Mientras se encuentra en medio de la escritura del código, un desarrollador es más apto para escribir un mensaje de error útil para sí mismo, ya sea para depurar el código que está escribiendo en este momento, o útil para los casos de uso conocidos o predominantes.

Cambiar de escribir código a diseñar una parte textual de la interfaz de usuario (o experiencia del usuario) es un cambio de contexto. En aplicaciones grandes, como las aplicaciones multilingües que podrían significar que se entregan a una persona o equipo diferente (UI, traducción) en lugar de ser manejado completamente por el desarrollador, a menos que el desarrollador explique cuidadosamente el contexto del mensaje, se pueden obtener detalles importantes. Se pierde fácilmente.

Por supuesto, verificar y verificar el manejo de errores a menudo se considera de baja prioridad, siempre que se manejen los errores y excepciones (es decir, se detecten), no se le da mucho énfasis. Es un lugar mentalmente poco gratificante de la base de código para que lo evalúen los desarrolladores o el control de calidad, ya que las condiciones de error a menudo tienen una connotación negativa (es decir, error o falla) asociada a ellas.

mctylr
fuente
0

Creo que la razón es que el informe / manejo de errores siempre se realiza como un pensamiento posterior . Incluso cuando no están completamente pensados, en su mayoría son ciudadanos de segunda clase en el diseño general.

El software moderno generalmente consta de múltiples capas. Cuando su lógica de informe de errores se establece rápidamente sin pensarlo demasiado, a menudo es difícil reunir toda la información necesaria para presentar mensajes de error útiles.

Por ejemplo, el error se detecta en el back-end, pero necesita cierta información de las capas superiores para componer un mensaje de error completo. La mayoría de los buenos mensajes de error necesitan información de casi todas las capas (para darnos una visión completa de lo que sucedió en el sistema). El mensaje de error ideal sería "OK, primero recibimos una cadena, luego pasó por el analizador que dio algo gracioso, es posible que desee mirar allí. De todos modos, la cosa se pasó más abajo ..."

Hacerlo a menudo requeriría un acoplamiento innecesario si el mecanismo de informe de errores no fuera ciudadano de primera clase durante la fase de diseño. Supongo que a la mayoría de la gente le parece demasiado trabajo para hacer algo que no parece impresionante (¿a quién le gusta decir "¿Ves? Mi programa se bloqueó y el mensaje de error es útil").

kizzx2
fuente