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 .