La philosophie du laisser-aller d'Erlang - applicable ailleurs ?

Question

Les conseils d'Erlang (ou de Joe Armstrong ?) NE PAS utiliser la programmation défensive et laisser les processus se planter (plutôt que de polluer votre code avec des gardes inutiles essayant de garder la trace de l'épave) a tellement de sens pour moi maintenant que je me demande pourquoi j'ai gaspillé tant d'efforts sur la gestion des erreurs au fil des ans !

Ce que je me demande, c'est si cette approche ne s'applique qu'à des plateformes comme Erlang. Erlang a une VM avec un support natif simple pour les arbres de supervision de processus et le redémarrage des processus est vraiment rapide. Devrais-je consacrer mes efforts de développement (quand je ne suis pas dans le monde d'Erlang) à recréer des arbres de supervision plutôt que de m'embourber dans des gestionnaires d'exceptions de haut niveau, des codes d'erreur, des résultats nuls, etc etc etc.

Pensez-vous que ce changement d'approche fonctionnerait bien dans (disons) l'espace .NET ou Java ?

Answer 1

Il est applicable partout . Que vous écriviez ou non votre logiciel selon le modèle "laissez-le se planter", il se plantera de toute façon, par exemple en cas de défaillance matérielle. Le modèle "Let it crash" s'applique partout où vous devez résister à la réalité. Quoth James Hamilton :

Si une panne matérielle nécessite une action administrative immédiate, le service ne pourra tout simplement pas évoluer de manière rentable et fiable. L'ensemble du service doit être capable de survivre à une panne sans interaction administrative humaine. La reprise après défaillance doit être très simple et doit être testée fréquemment. Armando Fox, de Stanford, a affirmé que la meilleure façon de tester le chemin de la défaillance n'est jamais d'arrêter le service normalement. Il suffit de le faire tomber en panne. Cela semble contre-intuitif, mais si les voies de défaillance ne sont pas fréquemment utilisées, elles ne fonctionneront pas en cas de besoin.

Cela ne signifie pas précisément "ne jamais utiliser de gardes". Mais n'ayez pas peur de vous écraser !

Answer 2

Oui, il est applicable partout, mais il est important de noter dans quel contexte il est censé être utilisé. Il ne no signifie que l'application dans son ensemble se plante, ce qui, comme l'a souligné @PeterM, peut être catastrophique dans de nombreux cas. L'objectif est de construire un système qui, dans son ensemble, ne se bloque jamais mais peut gérer les erreurs en interne. Dans notre cas, il s'agissait de systèmes de télécommunication dont les temps d'arrêt sont de l'ordre de quelques minutes par an.

La conception de base consiste à superposer le système et à isoler les parties centrales du système pour surveiller et contrôler les autres parties qui effectuent le travail. Dans la terminologie de l'ANP, nous avons superviseur y travailleur processus. Les superviseurs ont pour tâche de surveiller les travailleurs, et d'autres superviseurs, dans le but de les redémarrer correctement lorsqu'ils tombent en panne, tandis que les travailleurs effectuent tout le travail réel. Structurer correctement le système en couches en utilisant ce principe de séparation stricte des fonctionnalités vous permet d'isoler la plupart de la gestion des erreurs des travailleurs vers les superviseurs. Vous essayez de vous retrouver avec un petit un noyau d'erreur à sécurité intégrée, qui, s'il est correct, peut gérer les erreurs dans tout le reste du système. C'est dans ce contexte que la philosophie "let-it-crash" est censée être utilisée.

Vous obtenez le paradoxe suivant : vous pensez aux erreurs et aux défaillances partout dans le but de les traiter dans le moins d'endroits possible.

La meilleure approche pour traiter une erreur dépend bien sûr de l'erreur et du système. Parfois, il est préférable d'essayer d'attraper les erreurs localement au sein d'un processus et d'essayer de les traiter là, avec la possibilité d'échouer à nouveau si cela ne fonctionne pas. Si vous avez un certain nombre de processus de travail qui coopèrent, il est souvent préférable de les planter tous et de les redémarrer à nouveau. C'est un superviseur qui fait cela.

Vous avez besoin d'un langage qui génère des erreurs/exceptions lorsque quelque chose ne va pas, afin de pouvoir les piéger ou de les faire planter le processus. Ignorer les valeurs de retour des erreurs n'est pas la même chose.

Answer 3

J'écris des programmes qui s'appuient sur des données provenant de situations réelles et s'ils tombent en panne, ils peuvent causer des dommages physiques importants (sans parler du manque à gagner). Je perdrais mon emploi en un clin d'œil si je ne programmais pas de manière défensive.

Cela dit, je pense qu'Erlang doit être un cas particulier, car non seulement vous pouvez redémarrer les choses instantanément, mais un programme redémarré peut apparaître, regarder autour de lui et dire "ahhh c'est ce que je faisais !".

Answer 4

Cela s'appelle le fail-fast. C'est un bon paradigme à condition que vous disposiez d'une équipe de personnes capables de réagir à l'échec (et de le faire rapidement).

Dans la marine, tous les tuyaux et l'électricité sont montés à l'extérieur d'un mur (de préférence sur le côté le plus public d'un mur). De cette façon, s'il y a une fuite ou un problème, il est plus probable qu'il soit détecté rapidement. Dans la NAVY, les gens sont punis s'ils ne réagissent pas à une défaillance, donc cela fonctionne très bien : les défaillances sont détectées rapidement et on y donne suite rapidement.

Dans un scénario où quelqu'un ne peut pas agir rapidement sur une défaillance, la question est de savoir s'il est plus avantageux de laisser la défaillance arrêter le système ou d'avaler la défaillance et d'essayer de continuer.

Answer 5

Mes collègues et moi-même de la pensée sur le sujet n'est pas spécialement de la technologie sage, mais plus à partir d'un domaine perspective et avec une sécurité.

La question est "Est-il sécuritaire de le laisser tomber?" ou mieux "Est-il même possible d'appliquer une robustesse paradigme comme Erlang "let it crash" liés à la sécurité du logiciel projets?".

Afin de trouver une réponse, on a fait un petit projet de recherche à l'aide d'un proche de la réalité scénario avec des industriels et surtout des antécédents médicaux. Jetez un oeil ici (http://bit.ly/Z-Blog_let-it-crash). Il y a même un papier pour le téléchargement. Dites-moi ce que vous en pensez!

Personnellement, je pense que c'est applicable dans de nombreux cas, et même souhaitable, surtout quand il y a beaucoup d'erreur de manipulation à faire (systèmes relatifs à la sécurité). Vous ne pouvez pas toujours utiliser Erlang (manque le temps réel, pas de réel intégré de soutien, costumes voeux ...), mais je suis sûr que vous pouvez mettre en œuvre dans le cas contraire (par exemple, en utilisant des fils, les exceptions, la transmission de messages). Je n'ai pas encore essayé, mais j'aimerais.