design - examples - error messages

¿Qué debería incluirse en la estrategia de manejo de excepciones y errores de última generación? (6)

Entiendo que esta es una pregunta muy amplia, pero no se aceptará una breve respuesta tipo "depende". Las estrategias nacen para tratar problemas amplios.

¿Qué problemas debe tener en cuenta un diseñador de aplicaciones al diseñar la estrategia de manejo de errores y excepciones?
¿Cómo diferirá la estrategia según el tipo de software (COTS, aplicación empresarial interna, software de consultoría, juego, aplicación web alojada, incrustado, etc.)? ¿El tipo de software es importante?
¿Problemas éticos, políticos y legales?
Varias perspectivas sobre el manejo de errores (usuario, desarrollador, soporte comercial, administración).

Algunas ideas que habría explorado:

Varias rutas de informes de errores (es decir, interfaz de usuario, registro, notificación automática de administrador).
Defensa en profundidad y robustez (contingencia de failover y mecanismos a prueba de fallas, recuperación contra problemas que aún no se conocen).
Tratar a los usuarios y clientes de manera justa (es decir, minimizar el impacto en los usuarios del software y otras personas atendida por el software).

Estoy buscando una lista similar de ideas y conceptos.

Utilice los comentarios para señalarme si necesito aclarar la pregunta y agradecer a todos los que contribuyeron.

Preguntas más frecuentes

La plataforma de desarrollo (Java, .NET, móvil) : definitivamente tendrá algún efecto en los detalles de implementación resultantes de la estrategia desde la perspectiva del desarrollador pero menos desde el punto de vista de los usuarios.

Día de los tontos , ciertamente no lo es. La mayoría de los sistemas heredados en los que se me pidió que trabajara no tenían una clara estrategia de manejo de errores.

¿Podría hacerse esto una wiki comunitaria? No. Parece una buena pregunta y es difícil encontrar buenas preguntas.

¿Qué quieres decir con la estrategia? Un plan a largo plazo que brinda dirección, enfoque, brinda consistencia y coordinación al manejo de errores y excepciones. En el caso de un equipo más grande que trabaje en software, la estrategia puede formarse y distribuirse por escrito.

Parece ser una pregunta duplicada (consulte Prácticas recomendadas para la administración de excepciones en Java o C y que, y por qué prefiere las excepciones o los códigos de retorno ). Estas preguntas tienen que ver con cierta perspectiva sobre el manejo de errores (principalmente desarrollador), me gustaría aprender más sobre otras perspectivas y cómo contribuyen a la estrategia general.

Aquí hay muchas respuestas posibles, pero lo intentaré un poco.

¿Qué problemas debe tener en cuenta un diseñador de aplicaciones al diseñar la estrategia de manejo de errores y excepciones?

Cuando tiene múltiples desarrolladores, debería ser fácil "conectar" su marco de manejo de errores, de lo contrario la gente no lo usará.
Use las transacciones sabiamente para mantener la consistencia de los datos. Veo aplicaciones todo el tiempo donde podría ocurrir una falla a la mitad de un proceso y causar incoherencias de datos extraños porque toda la operación no se ha retrotraído correctamente.
Considere la importancia crítica cuando maneja excepciones. Por ejemplo, si tiene un sistema de pedidos en línea y parte de ese flujo de trabajo es enviar un correo electrónico al propietario del sitio para informarle que se realizó un nuevo pedido. Si el correo electrónico fallara, ¿el usuario debería recibir un error y cancelar el pedido completo?

¿Cómo diferirá la estrategia según el tipo de software (COTS, aplicación empresarial interna, software de consultoría, juego, aplicación web alojada, incrustado, etc.)? ¿El tipo de software es importante?

Para el tipo de escritorio o aplicaciones integradas, la grabación de información sobre el entorno (versión del sistema operativo, hardware, otras aplicaciones en ejecución, etc.) puede ser muy útil cuando se investigan informes de errores.
Para aplicaciones empresariales y aplicaciones web, cosas como las notificaciones de errores de correo electrónico, la mensajería SMS y la integración con herramientas ECO (por ejemplo, Tivoli) se vuelven muy útiles.

¿Problemas éticos, políticos y legales?

Lo único que se me ocurre aquí sería para aplicaciones de escritorio: las aplicaciones tipo "teléfono en casa" generalmente son mal vistas, especialmente si envían información sobre la máquina de los usuarios que podría ser delicada.

Varias perspectivas sobre el manejo de errores (usuario, desarrollador, soporte comercial, administración).

Desde la perspectiva del usuario, trate de evitar errores diseñando la interfaz de tal forma que les resulte difícil cometer errores. No haga preguntas que el usuario probablemente no podrá responder (¿Abortar, reintentar, reprobar a alguien?)
Desde la perspectiva del desarrollador, querrá tanta información como sea posible para ayudar a diagnosticar lo que sucedió: seguimiento de la pila, información del entorno, etc.
Desde el punto de vista del soporte y la gestión empresarial, querrán saber qué hacer con el error (principalmente en un entorno empresarial): ¿quién es responsable de la aplicación (a quién debo llamar / page / etc?), Así como la criticidad y cualquier posible efecto secundario (por ejemplo, si este trabajo por lotes falla, ¿qué procesos comerciales afectarán?). La documentación escrita es tu amiga aquí.

Es importante obtener la mayor cantidad de información posible sobre los errores que se están produciendo en el equipo de desarrollo. Los archivos de registro son buenos en los casos en que no hay usuarios para experimentar la condición de error y puede estar seguro de que alguien está revisando el archivo de registro. El correo electrónico automático es ideal para aplicaciones basadas en servidor. Los mensajes de alerta son problemáticos porque los usuarios nunca los leen. Un truco que funcionó para mí es copiar un seguimiento de error detallado en el portapapeles mientras se muestra un error fácil de usar, luego entrenar a los usuarios para pegar el rastreo de errores en un informe de error de correo electrónico. El equivalente web es mostrar un mensaje amigable al enviar un error detallado en un correo electrónico al equipo de desarrollo desde el servidor.

Debería haber un registro de último recurso, en otras palabras, ¿qué sucede cuando escribir en el archivo de registro provoca un error? También debería haber una protección integrada contra los problemas tipo "aprendiz de brujo" en los que el manejo de errores bloquea el sistema. En los sistemas de escritorio, un código de manejo de errores descuidado puede dar como resultado una cascada interminable de cuadros de mensaje que no dejan otra opción que matar la aplicación, posiblemente perdiendo datos en el proceso. Se pueden producir problemas similares si el código de manejo de errores desencadena excepciones. El marco de manejo de errores debería detectar errores en el manejo de errores y dejar de informar errores si no hay una mejor opción.

Para los procesos por lotes vitales, nada supera una notificación proactiva de éxito. Si el correo electrónico "lote completo" no llega, el usuario sabe que algo está activo, incluso si el manejo del error es fubar.

Las excepciones deben ser atrapadas en los límites. Todos los controladores de eventos, funciones de componentes públicos y métodos de servicio deben detectar todas las excepciones que se produzcan. En algunos casos, volver a lanzar una excepción tiene sentido; por ejemplo, cuando se detecta una excepción en un método de servicio web, se debe lanzar una excepción SOAP. Pero es una mala idea permitir que un excpetion se filtre a través de un límite de componente automáticamente.

Por el contrario, generalmente es una mala idea detectar excepciones en métodos privados de clases, o en métodos que están anidados en medio de un complejo proceso interno de un componente. No tiene sentido manejar una excepción en este contexto a menos que pueda recuperarse de la excepción. Este código interno debe estar estructurado para que todos los recursos se liberen y las transacciones de la base de datos se retrotraigan en presencia de excepciones. Los bloques de captura en cada método son el signo de caos, el uso y, finalmente, los bloques son un signo de un marco de manejo de errores de sonido.

Recuerde que las excepciones son excepcionales (si las esperaba, ¡no se llamarían excepciones!) En lugar de tratar de anticipar cuándo podrían ocurrir errores, concéntrese en reforzar los límites de sus componentes. Incluso el código trivial que posiblemente no podría experimentar un error debería tener un bloque catch si se encuentra en un límite. De esta forma, cuando el código se modifique más tarde de manera inesperada, la arquitectura seguirá siendo válida.

Cada límite de componente puede requerir un mecanismo de notificación diferente. En el caso de los componentes diseñados para ejecutarse en diferentes contextos, proporcione una interfaz de manejo de errores que el código del cliente puede usar para detectar los mensajes de error. No olvide el registro de último recurso si alguien se olvida de enganchar la interfaz de manejo de errores.

Para resumir:

Obtenga información detallada del error de vuelta al equipo de desarrollo de manera confiable.
Errores de trampa siempre en los límites de los componentes y solo en los límites de los componentes.
Haga que todas las excepciones de código sean seguras.
No permita que el marco de tratamiento de errores se convierta en parte del problema.

Me encontré con algunos de estos problemas en el trabajo, aunque no tuve la oportunidad de explorarlo allí. Mis pensamientos:

¿Qué problemas debe tener en cuenta un diseñador de aplicaciones al diseñar la estrategia de manejo de errores y excepciones?

La estrategia ideal de manejo de excepciones sería una recuperación completa y el registro del error. El catch-22: si pudieras hacer tal cosa, ¿no lo hubieras escrito en el código en primer lugar? Como tal, no es realmente una "excepción" per se, además su complejidad de implementación es exponencial. El otro lado de esto sería en el ámbito de los sistemas autónomos y el enfoque del "software de autocuración". Creo que la estrategia más realista es intentar siempre forzar al sistema a un estado constante (es decir, daño mínimo). Siempre se verá obligado a sacrificar algo: pérdida o datos dañados, pérdida de recursos que reducen el rendimiento, etc. sin embargo, estar en un estado constante aumenta sus posibilidades de permanecer operativo a una capacidad disminuida en lugar de enfrentar un cierre total. Formalizar un estado consistente entre el equipo del proyecto podría significar establecer valores predeterminados naturales que se usarían como un estado de restablecimiento.

Creo que cada tipo de software se presta a diferentes requisitos de auditoría y QoS, y se refleja en los costos asociados con el tiempo de inactividad y / o corrupción de datos; sin embargo, la estrategia general es la misma. Con incrustado, la estrategia es minimizar la apariencia del problema para el usuario y crear registros. Puede lograr esto reiniciando el software silenciosamente (es decir, reiniciando el estado). Con las aplicaciones web alojadas, los datos de sesión de un bloqueo se pueden descargar para su posterior análisis y el usuario obtiene una nueva sesión. Para un juego (especialmente para cosas como MMORPG), inviertes en el mantenimiento de datos de instantáneas para evitar que los jugadores pierdan el progreso en caso de falla del servidor. Las técnicas de clustering y fail-over del servidor también son muy importantes en estas implementaciones.

¿Problemas éticos, políticos y legales?

La transparencia es probablemente la parte más importante del manejo de errores y excepciones, que vendría en la forma de mantener la auditoría. El resultado final de esos problemas es demostrar que la falla del sistema (si se produce algún daño colateral) es el resultado de una cadena de eventos impredecibles que no pueden ser razonablemente previstos por los diseñadores. También es importante demostrar que cualquier mecanismo de manejo implementado tuvo un efecto positivo al reducir los daños, etc. También es importante mantener a los usuarios al día frente a una falla catastrófica (es decir, "¿A dónde se dirigió mi servidor WoW?" ), pero mi punto principal es que la transparencia debe aplicarse a la auditoría disciplinada a los fines de reconstruir el error.

Varias perspectivas sobre el manejo de errores (usuario, desarrollador, soporte comercial, administración).

Como usuario, el manejo de errores debe ser totalmente invisible. Si un servidor se bloquea, todavía quiero que mi transacción bancaria se complete según lo programado sin tener que llamar al banco y volver a ejecutar la transacción.

Como desarrollador, el manejo de errores es la parte más difícil de la aplicación para diseñar. La cantidad de cosas que pueden salir mal, resultantes tanto de personas como de factores tecnológicos, y cómo clasificarlas en casos en los que podemos escribir códigos para manejarlas es inmensamente difícil. Dependemos del presupuesto y la administración del proyecto para guiar estas decisiones, pero al final, sigue siendo como jugar a la ruleta rusa.

Para soporte y administración de negocios, supongo que el manejo de errores sería como el seguro pagado durante las fases de desarrollo de software, que reduce la incidencia de tener que compensar a los clientes que experimentan inconvenientes o interrupciones debido a fallas de software. También es una medida de la calidad del software y la responsabilidad (es decir, quieren saber qué división / grupo / desarrollador fue el responsable).

No tengo la intención de ganar recompensas, pero aquí hay algunas estrategias que he usado y que fueron bien recibidas:

La extracción de información de los subcomponentes y su asignación a unidades funcionales ayudó a nuestros analistas de negocios y usuarios finales a comprender mejor los errores.
Asignar un nivel de prioridad empresarial le ayudará según el dominio que esté operando.
Una aplicación de visor de errores separados nos ayudó a ver los errores antes de que se informaran para que mis equipos puedan empezar a corregirlos.
Las excepciones a nivel del sistema son mejores cuando no se les molesta.
El registro asincrónico de errores ayudará mucho en la estrategia y el diseño en general.
Crear una estrategia de error basada en el dominio: es decir, los errores podrían corresponderse con la falla de alguna lógica comercial. Por supuesto, la mayoría debe ser manejada por los desarrolladores, pero existen ciertos escenarios con los que se puede encontrar si está trabajando en el enrutamiento de mensajes entre varias empresas en motores de comercialización, etc.

Vengo de un fondo Java, pero mi respuesta también debería aplicarse a .Net.

Reglas de juego:

Escribe tu código para fallar rápido: Hunt & Thomas ; Consejo 33
Pruebe todos sus parámetros con una biblioteca de verificación param: estas no son condiciones excepcionales. Son mal uso de la API (documentada). Ejemplo: google collections Predicates
Use Excepciones para condiciones excepcionales: [Hunt & Thomas]; Consejo 34. Las excepciones NO se deben usar como códigos de retorno.
Prueba de condiciones excepcionales: las excepciones son condiciones posteriores para las invitaciones de métodos. Si no puede llegar allí con una prueba, la excepción no debe declararse.
(Para Java) Siga los consejos de Josh Bloch (todos del Capítulo 9). Algunos consejos importantes: 5a. Lanzar excepciones apropiadas para la abstracción. 5b. Esforzarse por la atomicidad del fracaso. 5c. Incluya información de captura de falla en el mensaje de detalle (o encuéntrela en la Excepción misma). 5d. No ignore las Excepciones.

<opening my mind to new concepts>

Grafique el flujo de error que ocurre a través de la impresora análoga tickertape o rollo de supervisión de terremotos, examine el progreso de una semana y compárelo con datos históricos, datos de uso y compárelos con los objetivos preestablecidos. Temporalmente coloque el gráfico largo impreso largo en las paredes y reúna al equipo de programación para una revisión. Usted compra sus bebidas, mientras explica su pregunta, esta vez muy específicamente, para que los programadores sepan exactamente para qué necesita una estrategia. Apuesto a que ese coffebreak soltero dará una respuesta estratégica efectiva y satisfactoria a su pregunta.

<closing my mind to new contepts>