Pourquoi les erreurs sont-elles nommées «Exception» mais pas «Erreur» dans les langages de programmation?

J'y réfléchis depuis un certain temps en fait. Je ne parle pas moi-même l'anglais, mais j'ai quand même des années d'expérience en programmation et je l'ai toujours demandé. Pourquoi est-il nommé comme Exception mais pas Erreur puisqu'il s'agit d'erreurs.

Cela pourrait être à la PageNotFoundErrorplace de PageNotFoundException.

Ils n'ont pas besoin d'être des erreurs du tout. Le fait que la page ne soit pas affichée peut être simplement un fait intéressant plutôt qu'une erreur réelle. Ils semblent s'être habitués presque toujours à des erreurs, je l'avoue. Mais parfois, ils sont habitués à rompre les boucles ou à vous faire savoir qu'une chaîne n'est pas un nombre valide. Ils peuvent être utilisés pour conserver et renvoyer de grandes quantités de données utiles - dans le cadre d'un retour assez normal. (Certaines langues sont un peu lentes avec leurs exceptions, dans ce cas, les lancer fréquemment est une mauvaise idée.) En théorie, une exception signifie simplement "ne faites pas de retour normal, remontez la pile d'appels jusqu'à ce que vous trouviez quelqu'un intéressé. dans ce."

Même une exception de pointeur nul pourrait ne pas avoir grand-chose pour vous. Vous appelez le code de quelqu'un d'autre, puis vous capturez une exception de pointeur NULL car vous savez qu'il est susceptible de exploser, vous imprimez un message indiquant à qui la faute incombe et vous poursuivez pour que votre travail soit terminé.

Le mécanisme des exceptions n'est pas toujours utilisé pour signaler des erreurs. Les exceptions sont renvoyées dans des situations inhabituelles nécessitant un chemin de code distinct, y compris les erreurs. Par exemple, un utilisateur fournissant un nom de fichier qui n'existe pas ou saisissant une lettre au lieu d'un chiffre dans un champ numérique est une situation exceptionnelle nécessitant un traitement spécial, mais il ne s'agit pas d'erreurs.

Dans certains environnements de programmation, tels que Java, des Errorobjets spéciaux sont fournis pour signaler des "erreurs vraies", situations qu'une application raisonnable ne devrait pas tenter de gérer. Ces objets sont livrés en utilisant le même mécanisme que celui utilisé pour les exceptions, mais ils ont une signification particulière en tant que signaux de situations irrécupérables.

Je n'ai pas de recherche étymologique sur les origines de cela, mais je peux comprendre que l'utilisation du terme "Erreur" peut ne pas être précise dans toutes les situations; comme le mentionne presqueSharepointMaster, il est préférable de penser à l’erreur et à l’exception levées en tant qu’entités séparées.

Lorsque vous utilisez un langage de programmation de haut niveau, il est logique de supposer qu'une exception est toujours causée par une erreur, bien que je sois également d’accord avec dasblinkenlight, même si une exception n’est pas toujours la conséquence d’une erreur. Par exemple, j'utilise des exceptions pour terminer les threads en collaboration.

La première fois que j'ai vu le terme "exception", c'était dans le manuel d'assemblage 80386. Je me souviens que lorsque j'ai vu cela me semblait instantanément naturel. Appeler cela une erreur ne serait pas correct, car il n'y a pas d'erreur dans Assembly; il y a simplement des conditions que le processeur ne peut pas gérer (si c'est une erreur - du programmeur, de l'utilisateur ou du système - eh bien, le processeur est complètement agnostique à cela). Je ne sais pas si Intel est vraiment à l'origine du terme ou non, mais peut-être ...

Communément Exception est utilisé pour nommer un événement incorrect, sur lequel il est possible de récupérer, comme une out_of_rangeexception en C ++, qui est levé lors de l'accès à un élément d'un vecteur ou d'un tableau inexistant. Clairement, un tel événement n’est pas correct, mais cela ne devrait pas vouloir dire que tout votre programme se bloque.

D'autre part, des erreurs sont généralement utilisées pour nommer quelque chose qui devrait tout écraser, un débordement de pile, par exemple, est un exemple d'événement qui devrait mettre fin au programme car le programme ne peut pas le gérer en interne. En d'autres termes: une erreur est majeure alors qu'une exception est comparativement mineure.

Je pense que cela a plus à voir avec "l'évolution" de la gestion des erreurs. Avec C / C ++ (avant que la gestion des exceptions ne soit ajoutée), si une fonction échouait, le seul moyen de le savoir était d'utiliser la valeur de retour (par exemple, HRESULTdans win32). En règle générale, vous avez attrapé les codes de sortie de chaque appel de fonction et effectué une vérification. Cette approche rend le code plus compliqué. Et bien souvent, les développeurs éviteront simplement d’ajouter ces vérifications par paresse.

Avec l'introduction de la gestion des exceptions, les développeurs avaient maintenant deux options pour générer une erreur. Le mot "exception" a donc été utilisé pour distinguer les erreurs des erreurs "état de sortie". Après un certain temps, la gestion des exceptions est devenue un moyen répandu de propagation des erreurs car le code est beaucoup plus facile à lire et à gérer et qu'il peut exister un seul endroit où vous pouvez avoir une logique de gestion des erreurs.

En Python, ils sont nommés ABCError. Par exemple: KeyError, IndexError.

http://docs.python.org/library/exceptions.html

Donc, je pense que cela dépend de la langue que vous utilisez.

En cas d'erreur, le système ou l'application en cours d'exécution le signale en générant une exception contenant des informations sur l'erreur. Une fois levée, une exception est gérée par l'application ou par le gestionnaire d'exceptions par défaut.

Une erreur déclenche une exception qui détaille l'erreur, ainsi tout n'est pas nécessairement une erreur si cela a du sens;), par exemple, une exception nonimplemeted ne devrait pas être une erreur, mais une exception.

http://msdn.microsoft.com/en-us/library/system.exception.aspx

Dans la programmation iOS / Mac, nous avons à la fois des exceptions et des erreurs dans un seul langage.

Au moins dans cet environnement, une exception est "non récupérable", tandis qu'une erreur est "récupérable".

Par exemple:

• si vous avez un tableau de 10 éléments et que vous essayez d'accéder à l'élément de l'index 30, il s'agira d'une exception. Vous avez commis une erreur dans votre programmation.
• si vous essayez de télécharger une URL sans connexion Internet, il faut s'y attendre et présenter un type de message à l'utilisateur.

Les exceptions bloquent généralement votre application, tandis que les erreurs renvoient généralement nilun objet d'erreur (renvoyé en tant que paramètre de méthode par référence). Vous pouvez intercepter des exceptions avec un bloc try / catch / finally, mais il est recommandé de ne jamais utiliser cette fonction de langage. S'il est possible de récupérer une exception de quelque manière que ce soit, vous ne devriez pas lancer d'exception du tout (vous devez retourner un objet d'erreur à la place).

Une erreur est quelque chose qui a mal tourné lors de l'exécution du programme. Ceci est souvent traité en levant une exception , mais

• rien n'oblige un programmeur à traiter une erreur en générant une exception, et
• rien n'oblige un programmeur à générer des exceptions uniquement en cas d'erreur.

L'erreur est un concept sémantique : il est appliqué par le programmeur ou l'utilisateur, qui vient au programme avec des attentes, pour décrire la différence entre leurs attentes et la réalité. Seule une personne peut dire si une routine est dans un état d'erreur ou non.

Une exception est un concept syntaxique : c'est quelque chose dans le programme lui-même, indépendant des attentes de quiconque quant à ce que ce programme est censé faire. Une routine crée ou non une exception, indépendamment de ce que quiconque pense.

Les exceptions et les erreurs sont différentes.

Les exceptions sont des situations qu'un programme peut surmonter, par exemple si vous essayez d'ouvrir un fichier mais qu'il n'existe pas, alors que les erreurs sont des situations dans lesquelles un programme ne peut rien faire, comme une panne de disque ou une RAM.

L'augmentation et la gestion des exceptions sont des fonctionnalités de flux de contrôle et le nom de l'exception doit suivre l'utilisation prévue. Le concepteur du code et de l’API doit trouver des schémas de nommage corrects et cohérents.

La réponse à votre question est donc la suivante: cela dépend du contexte et de la perspective.

Les exceptions ont évolué en tant que généralisation des erreurs. Le premier langage de programmation à inclure un mécanisme d’exception était Lisp au début des années 1970. Il y a un bon résumé dans A Pattern of Language Evolution de Gabriel et Steele. Les exceptions (qui n'étaient pas encore appelées exceptions) découlaient de la nécessité de spécifier le comportement d'un programme en cas d'erreur. Une possibilité consiste à arrêter le programme, mais ce n'est pas toujours utile. Les implémentations de Lisp avaient traditionnellement un moyen d'entrer dans le débogueur en cas d'erreur, mais les programmeurs voulaient parfois inclure la gestion des erreurs dans leur programme. Ainsi, les implémentations Lisp des années 1960 avaient un moyen de dire «faites ceci, et si une erreur se produit, faites-le plutôt». À l'origine, les erreurs provenaient de fonctions primitives, mais les programmeurs ont trouvé pratique de déclencher délibérément une erreur afin de sauter une partie du programme et d'accéder au gestionnaire d'erreurs.

En 1972, la forme moderne de gestion des exceptions dans Lisp est apparue dans MacLisp: throwet catch. Le groupe de préservation de logiciels répertorie de nombreux documents sur les premières implémentations de Lisp, y compris le manuel de référence MACLISP Révision 0 de David Moon . Les primitives catchet throwsont documentées au §5.3 p.43.

catchest la fonction LISP pour effectuer des sorties structurées non locales. (catch x)évalue xet renvoie ses valeurs, sauf que si, lors de l'évaluation, x (throw y)doit être évalué, catchretourne immédiatement ysans évaluation supplémentaire x.

catchpeut également être utilisé avec un argument econd, non évalué, utilisé comme étiquette pour distinguer les captures imbriquées. (…)

throwest utilisé avec catchcomme mécanisme de sortie non local structuré.

(throw x)évalue xet renvoie la valeur à la plus récente catch.

(throw x <tag>)renvoie la valeur de xretour à la plus récente catchétiquetée <tag>ou non étiquetée .

L'accent est mis sur le flux de contrôle non local . C'est une forme de goto (un goto ascendant), aussi appelé saut . La métaphore est que une partie du programme lance la valeur pour retourner au gestionnaire d'exceptions, et le gestionnaire d'exception prises cette valeur et retourne.

Aujourd'hui, la plupart des langages de programmation regroupent la balise et la valeur dans un objet exception et associent le mécanisme de capture à un mécanisme de traitement.

Les exceptions ne sont pas nécessairement des erreurs. Ils sont un moyen de sortir d'un bloc de code et des blocs environnants, en s'échappant jusqu'à ce qu'un gestionnaire pour l'exception soit atteint. Qu'une telle chose soit considérée comme une "erreur" au sens intuitif est subjectif.

Certaines langues font une distinction entre les termes «erreur» et «exception». Par exemple, certains dialectes Lisp doivent à la fois throwdéclencher une exception (flux de contrôle pour les utilisateurs, destiné à effectuer une sortie non locale d’une manière qui n’indique pas que quelque chose a mal tourné) et signalgénérer une erreur (ce qui indique que quelque chose a “mal tourné” et peut déclencher un événement de débogage).

Vous le trouverez interprété différemment dans différentes implémentations de langage de programmation. Comme Dasblinkenlight l’a dit, c’est un point de vue Java qui consiste à avoir une démarcation entre Erreur et Exception. Dans de nombreux langages de programmation, les exceptions sont des violations qui peuvent être gérées ou autorisées à être propagées pour être transmises au module de code le plus élevé possible. Les erreurs sont généralement des situations où le conteneur d’exécution de votre langue traite (et de nombreux cas arrêtent simplement l’exécution).

Une erreur est toujours une erreur. Une exception est une erreur dans le contexte actuel. C'est-à-dire qu'une exception est sensible au contexte. Un exemple d'exception serait l'ajout d'un ascii "a" à un entier "1". Une erreur peut ressembler à l'utilisation d'un opérateur non défini tel que "+!" dans la plupart des langues.

Certaines langues vous permettront de définir votre sortie de la situation si c'est vraiment ce que vous voulez faire.