Une petite note au cours de mon apprentissage d'Erlang sur la propagation des erreurs.
C'est un complément au chapitres 5 et 6 de cet
excellent livre.
Le problème en résumé :
Il s'agit d'un serveur hello world, dont la mise en oeuvre est assuré par
l'utilisation des behaviour supervisor et gen_server du framework
Erlang/OTP.
Le serveur propose du stockage clé/valeur et de la recherche sur les
clé.
Volontairement pour tester l'aspect "supervisor" de notre serveur, une
erreur dans la logique applicative (sur la fonction "retrieve/1") a été crée
afin de produire un crash et de vérifier si le processus supervisor effectue
correctement sa tâche :)
Pas de souci sur la mise en oeuvre de cet exemple mais comme le fait
remarquer l'ouvrage pour bien tester ce comportement il faut prendre une
précaution particulière :
Démarrer le supervisor et lancer une fonction cliente du serveur depuis 2
shell erlang différents.
La raison est simple, voici ce qu'il se passe si le démarrage du superviseur
et l'appel a une fonction cliente sont effectués depuis le même shell :
L'erreur coté serveur va provoqué un crash du processus effectuant l'appel
client (shell:eval).
Le processus shell:eval propage l'erreur jusqu'au supervisor (lui aussi
linké à notre shell:eval, car il a été lancé via la ligne de commande).
Le supervisor avec trap_exit a true va
recevoir le signal EXIT mais il ne gère que les signaux
EXIT correspondant au Pid du serveur hellosrv).
Il va se terminer,ne nous permettant pas de le tester (et verifier s'il a
bien redémarré le serveur hellosrv).
Le processus shell:eval se termine et un nouveau processus shell:eval est
créé.
voici les liens entre processus qui expliquent ce comportement :
Un comportement simple mais qui juste avec le livre, n'est pas forcement
évident à comprendre dans les moindres détails ;)
