Desenrollando el hilo negro del manejo errores

Presentado el 28 de Julio 2020 para Elixir Developers México
https://www.youtube.com/watch?v=sYFwwIV3T1Q
AGENDA
Manejo de errores en elixir.
Herramientas de recuperación de errores.
Conceptos de OO.
DoC.
Excepciones.

Transcript

1. Desenrollando el hilo negro del manejo de errores @d5lment 1
2. Agenda • Manejo de errores en elixir • Herramientas de recuperación de errores • Conceptos de OO • DoC • Excepciones • Conclusiones 2
3. Manejo de errores en Elixir 3
4. 3 tipos de errores en tiempo de ejecución error throw exit Sinónimo de excepciones 4
5. :error :throw :exit 5
6. :error • Es utilizado cuando se considera que algo excepcional pasa. • Para crearlo se utiliza la macro: raise/1 • Podemos crear nuestros propios errores con: defexception • Pueden ser rescatados utilizando: try-rescue 6
7. :error puede ser manejado con try-rescue Esto es rara vez utilizado Se evita para no controlar el flujo de ejecución mediante errores Es decisión de cada quién definir si un error es excepcional o no 7
8. Usar pattern-match para controlar el flujo 8
9. Convención en elixir sobre como usar error Cuando ocurre una situación considerada realmente un caso excepcional, se debe utilizar la función con el carácter “!” Es común encontrar: 1. File.read 2. File.read! ¿Debo tener 2 versiones de las funciones en mi código siempre? 9
10. :throw • En caso de necesitar controlar el flujo de la ejecución puedo usar throw. • Reservado para situaciones en las que necesite devolver un valor. 10
11. :exit • Los procesos tienen un mecanismo de señales, que envían antes de morir. • Proporcionan PID del proceso donde se realizó la salida y una razón. 11
12. Herramientas de recuperación de errores 12
13. links • Son la forma básica en que se puede detectar que un proceso murió. • Se pueden crear tantos links en el sistema como se necesiten. • Conectan siempre 2 procesos 13
14. monitors • Son procesos ligados a otros procesos de forma unilateral. • Un solo proceso puede tener múltiples monitores. • Si el proceso monitoreado muere se envía un mensaje al monitor. 14
15. exit trap • Es un mecanismo para propagar errores entre procesos • Permite decidir respecto a la falla. 15
16. Las herramientas de recuperación de errores links + exit traps + monitors Hacen posible la detención de errores en un sistema concurrente 16
17. ¡Los cabos sueltos! ¿sabemos definir, cuándo un error es excepcional o no? ¿ya sabemos qué es un sistema concurrente? 17
18. Time line • 1980 - Rymdbolaget - first interest in Fault-tolerance - Viking Satellite • 1985 - Ericsson -start working on “a replacement PLEX” -start thinking about errors - “errors must be corrected somewhere else” - “shared memory is evil” “pure message passing” • 1986 - Erlang - unification of OO with FP • 1986 - Several products in Erlang - Erlang is banned • 1998 .. 2002 - Bluctail -> Altoon -> Nortel -> Fired • 2002 - I move to SICS • 2003 - Thesis • 2004 - Back to Ericsson • 2015 - Put out to grass “The Do's and Don'ts of Error Handling” Siguiendo la pista 18
19. La tesis de Joe Trata de responder a la pregunta: ¿Cómo construir sistemas distribuidos confiables, en presencia de errores de software? 19
20. Plantea una filosofía 6 propiedades básicas que un sistema debe tener para ser tolerante a fallas • Concurrencia • Encapsulamiento de errores • Detección de fallas • Identificación de fallas • Actualización de código • Almacenamiento estable 20
21. Mucho en el diseño de la BEAM y del lenguaje en Erlang, se hizo pensando en las implicaciones de tener que coexistir con los errores Procesos ligeros Los procesos no comparten memoria Mucho en Erlang es acerca de los errores 21
22. Filosofía del manejo de errores • Deja que otros procesos realicen la recuperación de un error. • Si como proceso, no puedes completar tu objetivo, entonces: ¡muere! • Déjalo fallar • No programes defensivamente 22
23. ¡Más cabos sueltos! ¿Qué es tolerancia a fallas? ¿Qué es concurrencia? ¿Qué hace a un sistema confiable? ¿De qué hablan cuando dicen “programación defensiva”? 23
24. Conceptos OO 24
25. Definición de tolerancia a fallas Es la capacidad de construir sistemas confiables que pueden operar aún cuando enfrentan errores en tiempo de ejecución. 25
26. ¿Qué es la confiabilidad? Es la capacidad que tiene un sistema de software, de alcanzar los objetivos para los cuáles fue creado, bajo condiciones específicas, en periodos de tiempo determinados. 26
27. Diseño por contrato 27
28. ¿Cómo saber si el código es correcto? Es una noción relativa Comportamiento actual Comportamiento esperado Vs respecto a su especificación o contrato 28
29. La fórmula de la correctitud {P} A {Q} Postcondiciones Precondiciones CONTRATO S e p u e d e d e fi n i r u n a e s p e c i fi c a c i ó n , m e d i a n t e afirmaciones, que permiten evaluar si el software es correcto. Invariantes 29 Proveedor Cliente
30. Confiabilidad Correctitud Robustez Violaciones del contrato Cumplimiento del contrato Excepciones Afirmaciones 30
31. Elementos del mundo real Módulos de entrada y validación Módulos de procesamiento Estrategía de demanda Estrategia de tolerancia 31
32. Beneficios del DoC • Tener un mejor entendimiento del problema y de soluciones futuras. • Facilita la tarea de documentar. • Proporciona las bases para pruebas sistemáticas. ¿TDD? • Producir software que es presumiblemente consistente con su especificación, porque fue diseñado desde el inicio para serlo y además puede demostrar que lo es. 32
33. Excepciones Fallar Reintentar • Limpiar el ambiente • Terminar la llamada • Reportar la falla al cliente Debe contar con una manera de satisfacer las invariantes y las precondiciones 33
34. Conclusiones 34
35. Hacer el software tan sencillo como sea posible 35
36. Que hacer con los errores en tiempo de ejecución • Fallar rápido • Registrar el error en la bitácora • Agregar información que permita identificar el error • Hacer un re-intento • Cumplir con las invariantes + las precondiciones • Intentar hacer algo más simple 36
37. ¿Qué hacer como desarrollador? • Mantener el código simple • No hacer programación defensiva • Hacer pruebas automatizadas • Usar “property based testing” es una manera de utilizar las invariantes • Poner atención al diseño • Aplicar los conceptos de DoC • Dejar que alguien más resuelva el error: como la estructura de nuestro árbol de supervisión. • Revisar las referencias de esta plática 37
38. Es muy raro tener que inventar el hilo negro, casi siempre basta con solo con desenredarlo. ¡Gracias! 38
39. Referencias 1. The Do's and Don'ts of Error Handling: https://www.youtube.com/ watch?v=TTM_b7EJg5E 2. Tesis de Joe: http://erlang.org/download/ armstrong_thesis_2003.pdf 3. The zen of erlang: https://ferd.ca/the-zen-of-erlang.html 4. Let it crash meets it shouldn’t crash: https://www.youtube.com/ watch?v=OcbE6nL1QEk 5. Guía de inicio de elixir para: try, catch y rescue https://elixir- lang.org/getting-started/try-catch-and-rescue.html 6. Object Orientes Software Construction Bertrand Meyer 39