Diseñar para la escalabilidad con Erlang/OTP

Capítulo 8. Supervisores

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Ahora que somos capaces de monitorizar y gestionar errores predecibles, como quedarnos sin frecuencias, tenemos que abordar los errores inesperados que surgen como resultado de datos corruptos o fallos en el código. El problema es que, a diferencia de los errores devueltos al cliente por el asignador de frecuencias o las alarmas emitidas por los gestores de eventos, no sabremos cuáles son los errores inesperados hasta que se hayan producido. Podríamos especular, adivinar e intentar añadir código que gestione lo inesperado y esperar lo mejor. Utilizar herramientas automatizadas de generación de pruebas basadas en propiedades, como QuickCheck o PropEr, puede ayudar sin duda a crear escenarios de fallo que nunca idearías por tu cuenta. Pero, a menos que tengas poderes sobrenaturales, nunca podrás predecir todos los posibles errores inesperados que puedan producirse, y mucho menos manejarlos antes de saber cuáles son.

Con demasiada frecuencia, los desarrolladores intentan solucionar los fallos o los datos corruptos aplicando en su código sus propias estrategias de gestión y recuperación de errores, con el resultado de que aumentan la complejidad del código junto con el coste de mantenerlo (y, sin embargo, sólo manejan una fracción de los problemas que pueden surgir, y la mayoría de las veces acaban introduciendo en el sistema más fallos de los ...