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 ;)