Je connais une douzaine de langages de programmation qui ont des exceptions d'une certaine manière, pourtant j'en suis venu à être témoin de deux tendances "pathologiques".

1. Il ne semble pas y avoir de modèle ou de hiérarchie commun d'exceptions. Chaque langue roule essentiellement sa propre version, et si les exceptions en font la norme, alors les types d'exceptions que l'on trouve dans la norme seraient plutôt arbitraires (principalement ceux qui ont été implémentés lors de la création d'outils de langue, tels que la lecture du code source à partir de chaîne ou une exception pour appeler le débogueur, ou celle qui se produit lorsque le fichier est introuvable, etc.)

2. Les exceptions définies par le langage sont très rarement réutilisées par les programmes utilisateurs. Il y aurait généralement une ou deux exceptions courantes ("non implémenté" par exemple). Bien que la plupart du temps, les programmeurs créent leurs propres exceptions. (Comparez cela à, par exemple, la création de nouveaux types numériques ou de nouveaux types de collection).

Cela ressemble à une terrible omission pour moi. Comment se fait-il que personne ne sait quels types d'erreurs seront nécessaires dans les programmes utilisateur? J'espérais qu'il y aurait une sorte de belle hiérarchie, similaire aux types numériques, aux collections, au système d'objets, etc.

Pire encore, Goolge et Wikipedia fournissent très peu d'aide sur le sujet. Jusqu'à présent, je n'ai trouvé qu'un article sur l'exception fonctionnelle qui s'ouvre dans un passage:

Cet article soutient que la programmation fonctionnelle paresseuse rend non seulement inutile le mécanisme de gestion des exceptions intégré, mais fournit un outil puissant pour développer et transformer des programmes qui utilisent des exceptions

(Une théorie fonctionnelle des exceptions, Mike Spivey, 1988)

Mais je pense que les exceptions sont bonnes. Je ne veux pas transformer les programmes qui utilisent des exceptions, au contraire, je veux rendre l'utilisation des exceptions moins chaotique.

La question:

Existe-t-il une théorie des exceptions? Si oui, comment s'appelle-t-il? Quelles sont, le cas échéant, la pierre angulaire décrivant la base de celui-ci?

Il existe un grand nombre de publications sur les exceptions, avec pas mal de recherches théoriques. Voici une liste non structurée et loin d'être complète avec quelques exemples. Désolé, je n'ai pas le temps pour le moment pour une réponse plus ciblée.

• B. Randell, Structure du système pour la tolérance aux pannes logicielles.
• JB Goodenough. Gestion des exceptions: problèmes et proposition de notation.
• JB Goodenough. Gestion structurée des exceptions.
• BG Ryder, ML Soffa, Influence sur la conception de la gestion des exceptions.
• D. Teller, A. Spiwack, T. Varoquaux, Catch me if you can: Vers une gestion des erreurs sûre, hiérarchique, légère, polymorphe et efficace dans OCaml.
• X. Leroy, F. Pessaux, Analyse basée sur le type des exceptions non capturées.
• R. Miller, A. Tripathi, Problèmes de gestion des exceptions dans les systèmes orientés objet.
• S. Drew, KJ Gough, J. Ledermann, Implementation of Zero-Overhead Exception Handling.
• B. Stroustrup, Exception Safety: Concepts and Techniques.
• D. Malayeri, J. Aldrich, Spécifications d'exceptions pratiques.
• H. Nakano, Une formalisation constructive du mécanisme de capture et de lancer.
• A. Nanevski, Un calcul modal pour la gestion des exceptions.
• P. de Groote, Un calcul simple de la gestion des exceptions.
• H. Thielecke, Sur les exceptions et continuations en présence d'État.
• JG Riecke, H. Thielecke, les exceptions et les continuations typées ne peuvent pas s'exprimer en macro.
• M. van Dooren, E. Steegmans, Combinant la robustesse des exceptions vérifiées avec la flexibilité des exceptions non contrôlées à l'aide de déclarations d'exceptions ancrées.
• JA Vaughan, Une interprétation logique des exceptions de style Java.
• S. Marlow, S. Peyton Jones, A. Moran, Exceptions asynchrones dans Haskell.
• B. Jacobs, F. Piessens, Failboxes: Provably Safe Exception Handling.

Je ne sais pas s'il existe ou non une théorie, mais il peut y avoir une science expérimentale pragmatique émergente.

La meilleure source à laquelle je peux penser est Bjarne Stroustrup, The Design and Evolution of C ++, Addison-Wesley, 1994 . Si je me souviens bien (c'est un très bon livre et les gens continuent de me l'emprunter et de ne pas le retourner, donc je n'ai pas de copie pour le moment), il y a un chapitre sur les exceptions. Le comité C ++ de Stroustrup avait besoin de beaucoup de preuves empiriques qu'une fonctionnalité proposée était nécessaire avant de vouloir l'ajouter à la définition du langage. La page Wikipedia sur les exceptions a la citation suivante de ce livre:

Lors de la réunion de Palo Alto [normalisation C ++] en novembre 1991, nous avons entendu un brillant résumé des arguments pour une sémantique de terminaison appuyée à la fois par une expérience personnelle et des données de Jim Mitchell (de Sun, anciennement de Xerox PARC). Jim avait utilisé la gestion des exceptions dans une demi-douzaine de langues sur une période de 20 ans et était l'un des premiers partisans de la sémantique de reprise en tant que l'un des principaux concepteurs et réalisateurs du système Cedar / Mesa de Xerox. Son message était la résiliation est préférable à la reprise; ce n'est pas une question d'opinion mais une question d'années d'expérience. La reprise est séduisante, mais non valable. Il a soutenu cette déclaration avec l'expérience de plusieurs systèmes d'exploitation. L'exemple clé était Cedar / Mesa: il a été écrit par des gens qui aimaient et utilisaient la reprise, mais après dix ans d'utilisation, il n'y avait plus qu'une seule utilisation de la reprise dans le système d'un demi-million de lignes - et c'était une enquête contextuelle. Comme la reprise n'était pas réellement nécessaire pour une telle enquête contextuelle, ils l'ont supprimée et ont constaté une augmentation significative de la vitesse dans cette partie du système. Dans tous les cas où la reprise avait été utilisée, elle était devenue - au cours des dix dernières années - un problème et une conception plus appropriée l'avait remplacée. Fondamentalement, chaque utilisation de la reprise avait représenté un échec à maintenir des niveaux séparés d'abstraction disjoints. Dans tous les cas où la reprise avait été utilisée, elle était devenue - au cours des dix dernières années - un problème et une conception plus appropriée l'avait remplacée. Fondamentalement, chaque utilisation de la reprise avait représenté un échec à maintenir des niveaux séparés d'abstraction disjoints. Dans tous les cas où la reprise avait été utilisée, elle était devenue - au cours des dix dernières années - un problème et une conception plus appropriée l'avait remplacée. Fondamentalement, chaque utilisation de la reprise avait représenté un échec à maintenir des niveaux séparés d'abstraction disjoints.

En C ++, le véritable gain est RAII , ce qui facilite beaucoup la gestion de la désallocation des ressources lors d'erreurs. (Cela ne supprime pas le besoin de throwet try- catch, mais cela signifie que vous n'en avez pas besoin finally.)

Je pense que la chose qui les a convaincus qu'ils avaient besoin d'exceptions est les conteneurs génériques: l'auteur du conteneur ne sait rien des types d'erreurs que les objets contenus pourraient avoir besoin de renvoyer (encore moins comment les gérer), mais le code qui a inséré ces objets dans le le conteneur doit savoir quelque chose sur l'interface de ces objets. Mais comme nous ne savons rien des types d'erreurs que les objets contenus peuvent générer, nous ne pouvons pas standardiser les types d'exceptions. (Contrapositivement: si nous pouvions standardiser les types d'exceptions, nous n'aurions pas besoin d'exceptions.)

L'autre chose que les gens semblent avoir appris au fil des ans est que les spécifications d'exception sont difficiles à mettre correctement dans une langue. Voir par exemple ceci: http://www.gotw.ca/publications/mill22.htm , ou ceci: http://www.gotw.ca/gotw/082.htm . (Et ce n'est pas seulement C ++, les programmeurs Java ont également de longs arguments sur leurs expériences avec les exceptions vérifiées et non contrôlées .)

Un peu sur l'histoire des exceptions. L'article classique est: John B. Goodenough: "Traitement des exceptions: problèmes et proposition de notation", Commun. ACM 18 (12): 683-696, 1975. Mais des exceptions étaient connues avant cela. Mesa les avait vers 1974 et PL / I les avait peut-être aussi. Ada avait un mécanisme d'exception avant 1980. Je crois que les exceptions de C ++ ont été le plus influencées par l'expérience avec le langage de programmation CLU de Barbara Liskov vers 1976. Barbara Liskov: "A history of CLU", in History of programming languages ​​--- II , Thomas J. Bergin, Jr. et Richard G. Gibson, Jr. (éd.). pp. 471-510, ACM, 1996 .

Permettez-moi de souligner que les exceptions sont un cas d' effet de calcul . Les autres effets de calcul sont l'état mutable, les E / S, le non-déterminisme, les continuations et bien d'autres. Ainsi, votre question pourrait être posée de manière plus générale: comment former des hiérarchies d'effets de calcul, comment les organiser et pourquoi avons-nous ceux que nous avons, et pas d'autres, etc.