He leído acerca de cómo el estilo de programación fallido en lenguajes como Erlang termina con programas mucho más cortos que el estilo defensivo que se encuentra en la mayoría de los otros lenguajes. ¿Es esto correcto para todos los tipos de programas y cuál es el razonamiento para esto?¿Por qué los programas de estilo rápido son más cortos que los programas de estilo defensivo?
Los programas a prueba de fallos no son necesariamente más cortos que los programas de estilo defensivo: depende de la implementación y las medidas necesarias para proteger su código defensivo.
En el caso de Erlang, los programas a prueba de fallas suelen ser más cortos debido al estilo declarativo y a la forma en que la máquina virtual se asegura de generar casos de error para usted. Como ejemplo, en la función:
day(1) -> sunday;
day(2) -> monday;
day(3) -> tuesday;
day(4) -> wednesday;
day(5) -> thursday;
day(6) -> friday;
day(7) -> saturday;
Cualquier valor inesperado pasado a la función resultará en un error que puede ser capturado y manipulado por otro proceso (es decir .: un supervisor). Dichos errores nunca pondrán en peligro el sistema en su conjunto y no requieren que se agregue código a la función en sí; todo se hace fuera de la ruta de ejecución normal mediante comportamientos predeterminados.
En un lenguaje dinámico donde el fail-fast no es la norma, debería verificar manualmente los límites y lanzar una excepción usted mismo. Luego debe capturar la excepción localmente (capturas de prueba de nivel superior incluidas) si no desea que todo el sistema se apague. El código de manejo de errores generalmente debe insertarse a lo largo de la ruta de ejecución normal.
En un lenguaje estático donde el fail-fast no es la norma, el tiempo que su código dependerá en gran medida del tipo de sistema que tenga. Si el lenguaje permite definir los tipos en los que el compilador verificará los casos extremos, entonces generalmente no tiene que manejar esto dentro del código, fuera de eventos no determinísticos (archivos que no funcionan, entrada de usuario inesperada, etc.) idiomas con tales sistemas de tipo, muchos errores serán capturados antes del tiempo de ejecución y entonces no tendrás tantos casos defensivos.
Cuando no se puede evitar el manejo de errores, los lenguajes compatibles con fallos rápidos (como Erlang) permitirán un código más claro que los que no (estáticos o no), principalmente porque el código para casos especiales no es t mezclado con el código para la ruta de ejecución ideal.
El estilo de programación a prueba de fallos se centra en una mejor legibilidad y depuración del código. La experiencia del usuario es un objetivo secundario: un usuario puede experimentar extraños mensajes de error o fallas del programa, pero la mayor calidad del código permite a los programadores encontrar fácilmente el error y corregir el problema.
La programación de estilo defensivo, en cambio, se centra en la entrada de validación del usuario y de otras partes del código. El código es más detallado, porque el programador tiene que verificar cuidadosamente la entrada y falla con gracia en caso de error. Esto conduce a más código (desde el punto de vista de los programadores) y a una aplicación más robusta (desde el punto de vista de los usuarios).
No es correcto. Está confundiendo el estilo a prueba de fallas con un estilo sin manejo de errores.El estilo Fail-Fast aún le permite a su programa detectar errores y recuperarse de ellos sin molestar al usuario. – Deestan
Obviamente, el usuario también cosecha los beneficios de un software menos defectuoso con el estilo failfast. Preferiría decir que el fracaso tiene que ver con la claridad en lo que es la entrada correcta y la entrada incorrecta, y en hacer cumplir esto. La claridad invariablemente produce una mejor programación. Los errores en la entrada se deben marcar como tales (en lugar de tener la aplicación cojeando en un terreno no definido), pero eso no impide que la aplicación maneje este error de manera elegante e intuitiva. Creo que estás armando una dicotomía falsa. – harms
Respuesta incorrecta. En el contexto de Erlang, para el cual se formuló la pregunta, el enfoque más sólido es evitar la programación defensiva y simplemente dejar que el proceso ofensivo se "cuelgue". Otro proceso tomará las medidas apropiadas para recuperarse. En Java, que parece tener experiencia, no tiene más remedio que estar a la defensiva porque es un lenguaje imperativo con un modelo de concurrencia de estado compartido. Dado que Erlang es un lenguaje funcional con concurrencia de paso de mensajes, y debido a que existen mecanismos para comunicar fallas entre procesos, está perfectamente bien y es preferible que no falle. – dsmith
Vea las secciones 4.3 y 4.4 de Joe Armstrong's thesis.
El enlace está roto, pero aquí hay uno que funciona: http://erlang.org/download/armstrong_thesis_2003.pdf –
La sección 4.5 también es relevante, en mi opinión. –
Voy a romper con la tradición y preguntar por qué esto se hizo wiki comunitario. :) –
¿Debo cambiarlo para que no sea una wiki de la comunidad? Nunca estoy seguro de qué cosa es una wiki de la comunidad y cuál no. – Zubair
Lo bueno de la wiki de la comunidad es que las personas pueden editar cualquier respuesta para solucionarlo y no hay puntos de reenvío para el usuario que envió una respuesta, mientras que el modo normal da puntos y solo los usuarios con un número mínimo de puntos pueden editar las respuestas. –