Les exceptions sont-elles un concept de POO?

Après avoir lu un article hier, j'ai réalisé que je ne connaissais pas grand chose sur l'origine des exceptions. S'agit-il uniquement d'un concept lié à la POO? J'ai tendance à penser que c'est le cas, mais encore une fois, il existe des exceptions de base de données.

Les exceptions ne sont pas un concept OOP.

Mais ils ne sont pas non plus complètement indépendants l'un de l'autre.

Comme d’autres réponses l’ont montré: Le concept d’exception s’applique dans plusieurs langues autres que la programmation orientée objet. Rien dans ce concept n'exige quelque chose de la programmation orientée objet.

Cependant, tous les langages POO, si ce n'est tous, qui prennent sérieusement la POO requièrent des exceptions car les autres méthodes de traitement des erreurs échouent à un point spécifique: le constructeur.

Un des points de la programmation orientée objet est qu'un objet doit encapsuler et gérer son état interne de manière complète et cohérente. Cela signifie également qu'en pure POO, vous avez besoin d'un concept pour créer un nouvel objet avec un état cohérent "de manière atomique" - tout, de l'allocation de mémoire (si nécessaire) à l'initialisation à un état significatif (la mise à zéro de la mémoire ne suffit pas). être fait en une seule expression. Un constructeur est donc nécessaire:

Foo myFoo = Foo("foo", "bar", 42);

Mais cela signifie que le constructeur peut également échouer à cause d'une erreur. Comment propager l'information d'erreur du constructeur sans exception?

• Valeur de retour? Echoue car dans certaines langues, newseule nullune information significative peut être renvoyée. Dans d'autres langages (par exemple, C ++), ce myFoon'est pas un pointeur. Vous ne pouviez pas le vérifier null. Aussi, vous ne pouvez pas poser myFoode question sur l'erreur - elle n'est pas initialisée et donc "n'existe pas" dans la pensée de la programmation orientée objet.

• Indicateur d'erreur globale? Tant de choses sur l'état d'encapsulation et ensuite une variable globale? Allez à h ... ;-)

• Un mélange? En aucun cas mieux.

• ?

Les exceptions sont donc un concept plus fondamental que la POO, mais la POO les construit de manière naturelle.

Est-ce seulement lié à la POO?

Non. Les exceptions et la POO ne sont pas liées.

La gestion des exceptions est un mécanisme permettant de gérer les erreurs. Une exception est gérée en sauvegardant l'état d'exécution actuel dans un emplacement prédéfini et en basculant l'exécution vers un sous-programme spécifique appelé gestionnaire d'exceptions.

En comparant le langage C ( pas vraiment le langage OOP , il est possible d’émuler les exceptions en C ) et le C ++ (OOP, prend en charge les exceptions), rien n’empêche le comité standard de C d’ajouter le traitement des exceptions à C, il ne fera toujours pas de C un langage OOP.

Une exception est simplement une situation exceptionnelle qui nécessite une attention et souvent un changement dans le déroulement de l’exécution d’un programme. Selon cette définition, la gestion des exceptions et des exceptions ne se limite pas à l'orientation objet, et les erreurs de programme simples peuvent être considérées comme une forme d'exception.

Les langages orientés objet ont généralement une classe d'exception native et, en fonction du contexte, le mot "exception" peut en fait faire référence à cette classe native au lieu du concept général. La gestion des exceptions orientée objet est, comme l'essentiel de l'orientation objet, un sucre syntaxique, et peut être facilement imitée dans des langages résolument non orientés objet. Voici un exemple en C, tiré du wikibook Programmation C :

#include <stdio.h>
#include <setjmp.h>

jmp_buf test1;

void tryjump()
{
    longjmp(test1, 3);
}

int main (void)
{
    if (setjmp(test1)==0) {
        printf ("setjmp() returned 0.");
        tryjump();
    } else {
        printf ("setjmp returned from a longjmp function call.");
    }
}

La réponse est un simple NON.

ADA est un bon exemple de langage non-OO avec des exceptions.

Quelques très bonnes réponses ici déjà. Autres exemples de langages de programmation non-POO ayant des exceptions:

• Oracle PL / SQL

• Visual Basic classique (V6 et inférieur, "On Error Goto" est, à mon sens, une forme de gestion des exceptions)

(Pour être précis: vous trouvez des éléments OO dans les deux langues, mais le mécanisme de traitement des exceptions ne les utilise pas, je suppose, car le concept a été introduit des années avant l'ajout des éléments OO à ces langues).

L'idée de base derrière les exceptions est de nettoyer le flux du programme afin qu'un programmeur puisse suivre plus facilement le chemin d'exécution "normal". Prenons un cas simple d’ouverture d’un fichier en C. Immédiatement après avoir tenté d’ouvrir le fichier, le programmeur doit examiner la réponse de l’appel fopen () et décider s’il a réussi. Si l'appel n'a pas abouti, le programmeur doit répondre correctement. Le prochain appel dans le chemin d'exécution "normal", peut-être un appel à fread () ou à fwrite (), apparaîtra une fois que les conditions d'erreur ou d'échec auront été gérées. Cela peut être sur l'écran suivant.

Avec un langage fournissant des exceptions, l'appel fopen () équivalent peut être suivi immédiatement par fread () ou fwrite (). Il n'y a pas de traitement d'erreur qui cache la "prochaine étape" du chemin d'exécution "normal". Le programmeur peut voir plus du chemin normal sur un seul écran, et peut donc suivre l'exécution plus facilement. La gestion des erreurs est déplacée vers une autre partie du programme.

Les exceptions elles-mêmes ne sont pas un concept de programmation orientée objet, mais elles sont souvent mises en œuvre à l'aide de concepts de programmation orientée objet qui les rendent plus pratiques et plus puissantes. Par exemple, les exceptions peuvent être définies avec une hiérarchie d'héritage. En utilisant notre exemple théorique d'ouverture et de lecture ou d'écriture d'un fichier, chacun de ces appels peut générer diverses exceptions - FileClosedException, DeviceFullException, NoSuchFileException, InsufficientFilePermissionsException, etc. Chacun de ces appels peut hériter de FileException, qui peut hériter de IOException, qui peut hériter de GenericException.

Si le programmeur effectue une mise en œuvre rapide et incorrecte pour tester un concept, il peut en grande partie ignorer la gestion des exceptions et simplement mettre en œuvre un gestionnaire unique pour GenericException. Ce gestionnaire gérera une exception GenericException et toute exception héritant de GenericException. S'il veut traiter n'importe quelle exception liée au fichier de la même manière, il peut écrire un gestionnaire pour FileException. Cela sera appelé pour FileExceptions et toutes les exceptions héritant de FileException. S'il veut écrire un programme qui répondra différemment à diverses conditions d'erreur, il peut écrire un gestionnaire spécifique pour chaque exception spécifique.

D'autres ont à juste titre répondu «non» avec des exemples de langues. Je pensais pouvoir étendre mon propos en ajoutant un exemple sur la manière d’ajouter des exceptions à une langue sans jamais impliquer la POO.

Je le ferai dans le cas du langage DSKL (langage déclaratif du noyau séquentiel) d' OZ , un langage bien adapté à la vie académique comme celle-ci. Le DSKL (ou DKL) peut être vu ici (résultat de la recherche aléatoire), la partie Déclarations et valeurs. La définition exacte n’est pas importante, à part qu’il s’agit d’un langage très simple, sans variables modifiables (elles sont déclarées et ensuite liées), et pas de POO intégrée.

La programmation orientée objet ne peut même pas être ajoutée en tant qu'abstraction linguistique à cette langue du noyau. En ajoutant des noms uniques à la langue du noyau (NewName) et en utilisant la portée locale, l’encapsulation peut être réalisée. Ou en ajoutant un état modifiable à la langue du noyau (NewCell) et en utilisant une OOP de portée locale avec encapsulation appropriée. Mais cela ne peut pas être réalisé avec la seule langue du noyau spécifiée.

Si nous ajoutons ensuite des exceptions à la langue du noyau, nous aurons une langue sans prise en charge de la POO mais avec des exceptions. Laissez-moi vous montrer comment:

En définissant une machine abstraite avec une pile et un stockage, nous pouvons définir ce que chaque instruction de notre langage doit faire (la sémantique de l’instruction). Par exemple, skipdans la pile ne devrait rien faire, A = 3dans la pile devrait lier (/ unifier) ​​A à (/ avec) 3.

Nous commençons par ajouter la syntaxe de la manière dont nos exceptions doivent être définies. Pour ce faire, nous ajoutons deux autres clauses à <statement>la DKL.

<statement>  ::== ... (old stuff)
                 | try <statement> catch <id> then <statement> end
                 | raise <id> end

Voici le try / catch connu et un moyen de lever / jeter des exceptions.

Nous définissons leur sémantique par la façon dont ils devraient travailler sur la machine abstraite:

Try
La déclaration sémantique est: (try <statement1> catch <id> then <statement2> end)
Do:

1. Poussez sur la pile la déclaration sémantique (catch <id> then <statement2> end)
2. Poussez sur la pile la déclaration sémantique (<statement1>)

Notez que l'instruction 1 sera au-dessus de la pile et sera exécutée en premier.

Raise
L'énoncé sémantique est: (raise <id> end)
Do:

1. Si rien ne se trouve sur la pile, arrêtez et signalez une exception non capturée.
2. Sinon, extrayez la première déclaration sémantique de la pile. Si ce n'est pas une déclaration de capture, passez à l'étape 1.
3. Nous avons un piège, sur le formulaire (catch <id> then <statement> end)
   Poussez (<statement>)sur la pile.

Catch
Si nous voyons une instruction catch lors de l'exécution normale, cela signifie que tout ce qui était à l'intérieur a été exécuté sans générer d'exceptions jusqu'à ce niveau. Ainsi, nous sortons simplement catchde la pile et ne faisons rien.

CQFD, nous avons un langage avec des exceptions et aucune possibilité de POO.

_{J'ai supprimé la partie environnement de la machine abstraite pour la simplifier.}

Non.

IIRC, des exceptions sont apparues avant les premières langues OO. D'après les informations dont je dispose, les exceptions ont d'abord été prises en charge par les premières implémentations de LISP. Les premiers langages structurés (par exemple ALGOL) et les premiers langages OO (par exemple SIMULA) ne prenaient pas en charge les exceptions.