La première solution est impossible dans un langage généraliste, car dans ces langages, c'est un problème indécidable.
La deuxième solution permet juste de cacher un bug (donc conduisant à un comportement imprévu, potentiellement une faille) tout en ayant un coût en performances (à mon avis pas négligeable, mais à vérifier). Choix favorisant la disponibilité (faire quelque chose à tout prix) contre la correction et les performances. Peut-être raisonnable pour le web.
La troisième, c'est la même qu'un panic avec recover en Go : a priori utilisé uniquement en cas d'erreur vraiment exceptionnelle (le plus souvent provenant d'une erreur de programmation) pour un système où la disponibilité est plus importante que la correction. C'est a priori rattrapé assez près du main, dans le but de relancer le programme ou un sous-système de celui-ci, et pas à chaque division par zéro (autrement le code deviendrait imbitable). Du coup, ça rentre bien dans le cadre des utilisations potentielles de panic/recover. La différence pratique, c'est qu'en Go il y a une distinction au niveau langage entre une situation d'exception (issue d'une erreur de programmation) et une simple erreur à laquelle il est possible de réagir plus spécifiquement.
[^] # Re: Ouaiche
Posté par anaseto . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 2.
La première solution est impossible dans un langage généraliste, car dans ces langages, c'est un problème indécidable.
La deuxième solution permet juste de cacher un bug (donc conduisant à un comportement imprévu, potentiellement une faille) tout en ayant un coût en performances (à mon avis pas négligeable, mais à vérifier). Choix favorisant la disponibilité (faire quelque chose à tout prix) contre la correction et les performances. Peut-être raisonnable pour le web.
La troisième, c'est la même qu'un panic avec recover en Go : a priori utilisé uniquement en cas d'erreur vraiment exceptionnelle (le plus souvent provenant d'une erreur de programmation) pour un système où la disponibilité est plus importante que la correction. C'est a priori rattrapé assez près du main, dans le but de relancer le programme ou un sous-système de celui-ci, et pas à chaque division par zéro (autrement le code deviendrait imbitable). Du coup, ça rentre bien dans le cadre des utilisations potentielles de panic/recover. La différence pratique, c'est qu'en Go il y a une distinction au niveau langage entre une situation d'exception (issue d'une erreur de programmation) et une simple erreur à laquelle il est possible de réagir plus spécifiquement.