À mon avis, les exceptions sont un outil essentiel pour détecter les erreurs de code au moment de l'exécution. Tant dans les tests et dans la production. Faites en sorte que leurs messages soient suffisamment détaillés pour que, combiné à une trace de pile, vous puissiez savoir ce qui s’est passé dans un journal.
Les exceptions constituent principalement un outil de développement et un moyen d'obtenir des rapports d'erreur raisonnables de la production dans des cas inattendus.
Mis à part la séparation des problèmes (chemin heureux avec les erreurs attendues seulement, jusqu'à atteindre un gestionnaire générique d'erreurs inattendues), il est intéressant de rendre votre code plus lisible et maintenable, il est en fait impossible de préparer votre code pour tout ce qui est possible. cas inattendus, même en le gonflant avec un code de traitement des erreurs pour compléter l’illisibilité.
C'est en fait le sens du mot "inattendu".
Au fait, ce qui est attendu et ce qui ne l'est pas est une décision qui ne peut être prise que sur le site de l'appel. C'est pourquoi les exceptions vérifiées dans Java n'ont pas fonctionné - la décision est prise au moment de développer une API, quand il est difficile de savoir ce qui est attendu ou inattendu.
Exemple simple: l'API d'une carte de hachage peut avoir deux méthodes:
Value get(Key)
et
Option<Value> getOption(key)
le premier levant une exception s'il n'est pas trouvé, le dernier vous donnant une valeur optionnelle. Dans certains cas, ce dernier a plus de sens, mais dans d’autres, votre code doit absolument s’attendre à ce qu’il y ait une valeur pour une clé donnée. Par conséquent, s’il n’en existe pas, il s’agit d’une erreur que ce code ne peut corriger l'hypothèse a échoué. Dans ce cas, le comportement souhaité est de sortir du chemin du code et de passer à un gestionnaire générique en cas d'échec de l'appel.
Code ne doit jamais essayer de traiter des hypothèses de base qui ont échoué.
Sauf en les vérifiant et en jetant des exceptions bien lisibles, bien sûr.
Lancer des exceptions n'est pas mauvais, mais les attraper peut l'être. N'essayez pas de réparer des erreurs inattendues. Attrapez les exceptions dans quelques endroits où vous souhaitez continuer une boucle ou une opération, enregistrez-les, signalez peut-être une erreur inconnue, et c'est tout.
Les blocs de prise partout sont une très mauvaise idée.
Concevez vos API de manière à ce qu'il soit facile d'exprimer votre intention, c'est-à-dire d'indiquer si vous attendez un cas particulier, comme une clé non trouvée ou non. Les utilisateurs de votre API peuvent alors choisir l'appel de lancement uniquement pour des cas vraiment inattendus.
J'imagine que les mauvaises expériences sont la raison pour laquelle les gens refusent les exceptions et vont trop loin en omettant cet outil essentiel d'automatisation de la gestion des erreurs et de la séparation des préoccupations des nouvelles langues.
Cela, et certains malentendus sur ce qu’ils sont réellement bons pour.
Les simuler en faisant TOUT avec la liaison monadique rend votre code moins lisible et moins maintenable, et vous vous retrouvez sans trace de pile, ce qui rend cette approche bien pire.
La gestion des erreurs de style fonctionnel est idéale pour les cas d'erreur prévus.
Laissez la gestion des exceptions s'occuper automatiquement de tout le reste, c'est pour ça :)
panic
ce qui n’est pas tout à fait pareil. En plus de ce qui est dit là-bas, une exception n’est guère plus qu’un moyen sophistiqué (mais confortable) d’exécuter une actionGOTO
, bien que personne ne l’appelle ainsi, pour des raisons évidentes.