java - icon - La filosofía de dejarlo escapar de Erlang, ¿aplicable en otro lugar?
my icon java (6)
¿El consejo de Erlang (o Joe Armstrong?) De NO usar programación defensiva y dejar que los procesos fallen (en lugar de contaminar tu código con guardias innecesarios tratando de hacer un seguimiento de los restos) tiene tanto sentido para mí ahora que me pregunto por qué desperdicié tanto esfuerzo en el manejo de errores a través de los años!
Lo que me pregunto es: ¿este enfoque solo es aplicable a plataformas como Erlang? Erlang tiene una VM con soporte nativo simple para árboles de supervisión de procesos y los procesos de reinicio son realmente rápidos. ¿Debería dedicar mis esfuerzos de desarrollo (cuando no esté en el mundo de Erlang) a volver a crear árboles de supervisión en lugar de empantanarme con manejadores de excepciones de alto nivel, códigos de error, resultados nulos, etc. etc., etc.
¿Crees que este cambio de enfoque funcionaría bien en (digamos) el espacio .NET o Java?
En mi humilde opinión, algunos desarrolladores manejan / envuelven las excepciones marcadas con código que agrega poco valor. A menudo es más simple permitir que un método arroje la excepción original a menos que vaya a manejarlo y agregar algún valor.
Escribo programas que se basan en datos de situaciones del mundo real y si se bloquean pueden causar grandes $$ en daños físicos (sin mencionar los grandes $$ en ingresos perdidos). Me quedaría sin trabajo en un instante si no programara a la defensiva.
Dicho esto, creo que Erlang debe ser un caso especial que no solo puede reiniciar las cosas al instante, que puede reiniciarse un programa, mirar a su alrededor y decir "ahhh ... eso era lo que estaba haciendo".
Mis colegas y yo pensamos en el tema no especialmente en lo que se refiere a la tecnología, sino más desde una perspectiva de dominio y con un enfoque de seguridad.
La pregunta es "¿Es seguro dejar que se cuelgue?" o mejor "¿Es posible aplicar un paradigma de robustez como el de Erlang para" dejar que se cuelgue "a los proyectos de software relacionados con la seguridad?".
Para encontrar una respuesta hicimos un pequeño proyecto de investigación usando un escenario cercano a la realidad con antecedentes industriales y especialmente médicos. Eche un vistazo aquí ( http://bit.ly/Z-Blog_let-it-crash ). Incluso hay un papel para descargar. ¡Dime que piensas!
Personalmente, creo que es aplicable en muchos casos e incluso deseable, especialmente cuando hay que hacer un montón de errores (sistemas relacionados con la seguridad). No siempre se puede usar Erlang (funciones faltantes en tiempo real, sin soporte incrustado real, clientela ...), pero estoy bastante seguro de que puedes implementarlo de otra manera (por ejemplo, usando hilos, excepciones, mensajes pasados). No lo he intentado todavía, pero me gustaría.
Sí, es aplicable en todas partes, pero es importante tener en cuenta en qué contexto está destinado a ser utilizado. No significa que la aplicación en su totalidad falla, lo que, como señaló @PeterM, puede ser catastrófico en muchos casos. El objetivo es construir un sistema que en conjunto nunca se cuelgue, pero que pueda manejar los errores internamente. En nuestro caso, fueron los sistemas de telecomunicaciones los que se espera que tengan tiempos de inactividad del orden de minutos por año.
El diseño básico consiste en aplicar capas al sistema y aislar las partes centrales del sistema para supervisar y controlar las otras partes que hacen el trabajo. En la terminología de OTP tenemos procesos de supervisor y trabajador . Los supervisores tienen la tarea de supervisar a los trabajadores y otros supervisores, con el objetivo de reiniciarlos de la manera correcta cuando fallan mientras los trabajadores hacen todo el trabajo real. La estructuración adecuada del sistema en capas utilizando este principio de separación estricta de la funcionalidad le permite aislar la mayor parte del manejo de errores de los trabajadores en los supervisores. Intenta terminar con un pequeño kernel de error seguro, que si es correcto puede manejar errores en cualquier parte del resto del sistema. Es en este contexto donde la filosofía "let-it-crash" está destinada a ser utilizada.
Obtiene la paradoja de que está pensando en errores y fallas en todas partes con el objetivo de realmente manejarlos en el menor número posible de lugares.
El mejor enfoque para manejar un error depende, por supuesto, del error y del sistema. A veces es mejor tratar de detectar errores localmente dentro de un proceso y tratar de manejarlos allí, con la opción de fallar nuevamente si eso no funciona. Si tiene una cantidad de procesos de trabajo colaborativo, a menudo es mejor bloquearlos todos y reiniciarlos nuevamente. Es un supervisor que hace esto.
Necesitas un lenguaje que genere errores / excepciones cuando algo va mal para que puedas atraparlos o hacer que bloqueen el proceso. Ignorar los valores de retorno de error no es lo mismo.
Se llama fail-fast. Es un buen paradigma siempre que tenga un equipo de personas que pueda responder al fracaso (y lo haga rápidamente).
En la NAVY, todas las tuberías y las conexiones eléctricas están montadas en el exterior de una pared (preferiblemente en el lado más público de una pared). De esta forma, si hay una fuga o problema, es más probable que se detecte rápidamente. En la MARINA, las personas son castigadas por no responder a una falla, por lo que funciona muy bien: las fallas se detectan rápidamente y se actúa rápidamente.
En un escenario en el que alguien no puede actuar ante una falla rápidamente, se convierte en una cuestión de opinión si es más beneficioso permitir que la falla no detenga el sistema o que se trague la falla e intente continuar.
Es aplicable en todas partes . Ya sea que escriba o no su software en un patrón de "deje que se bloquee", se bloqueará de todos modos, por ejemplo, cuando falle el hardware. "Let it crash" se aplica en cualquier lugar donde necesites resistir la realidad. Quoth James Hamilton:
Si una falla de hardware requiere alguna acción administrativa inmediata, el servicio simplemente no se escalará de manera rentable y confiable. Todo el servicio debe ser capaz de sobrevivir al fracaso sin interacción administrativa humana. La recuperación de fallas debe ser una ruta muy simple y esa ruta debe probarse con frecuencia. Armando Fox, de Stanford, ha argumentado que la mejor forma de probar la falla es nunca cerrar el servicio normalmente. Sólo duro, no lo hagas. Esto suena contrario a la intuición, pero si las rutas de falla no se utilizan con frecuencia, no funcionarán cuando sea necesario.
Sin embargo, esto no significa precisamente "nunca usar guardias". ¡Pero no tengas miedo de chocar!