Exception Handling Overview

Le traitement des exceptions est le processus de:

Examen d'un message d'exception émis à la suite d'une erreur d'exécution
Modification facultative de l'exception pour indiquer qu'elle a été reçue (c'est-à-dire traitée)
Vous pouvez éventuellement effectuer une récupération à partir de l'exception en transmettant les informations d'exception à un élément de code pour effectuer les actions nécessaires.

Lorsqu'une erreur d'exécution se produit, un message d'exception est généré. Un message d'exception possède l'un des types suivants en fonction de l'erreur qui s'est produite:

*ÉCHAPPEMENT: Indique qu'une erreur grave a été détectée.
*ETAT: Décrit le statut du travail effectué par un programme.
*NOTIFY: Décrit une condition nécessitant une action corrective ou une réponse du programme appelant.
Vérification de la fonction: Indique que l'une des trois exceptions précédentes s'est produite et n'a pas été traitée.

Les messages d'exception sont associés à des postes de pile d'appels. Chaque entrée de liste d'appels est à son tour associée à une liste de gestionnaires d'exceptions définis pour cette entrée. (Voir La pile d'appels pour plus de détails sur une pile d'appels.)

La Figure 1 illustre une pile d'appels dans laquelle un programme OPM appelle un programme ILE composé de plusieurs modules et donc de plusieurs procédures. Reportez-vous à cette figure dans les discussions qui suivent.

En général, lorsqu'une exception se produit, les gestionnaires associés à l'entrée de la pile d'appels ont la possibilité de traiter l'exception. Si l'exception n'est pas gérée par l'un des gestionnaires de la liste, elle est considérée comme non gérée, à partir de laquelle les actions par défaut suivantes sont effectuées pour l'exception non gérée:

Si l'exception est une vérification de fonction, l'entrée de la pile d'appels est supprimée de la pile.
L'exception est déplacée (percolée) vers l'entrée de pile d'appels précédente.
Le processus de traitement des exceptions est redémarré pour cette entrée de pile d'appels.

L'action permettant à l'entrée de pile d'appels précédente de traiter une exception est appelée percolation. La percolation se poursuit jusqu'à ce que l'exception soit traitée ou que la limite de contrôle soit atteinte. Une limite de contrôle est une entrée de pile d'appels pour laquelle l'entrée de pile d'appels immédiatement précédente se trouve dans un groupe d'activation différent ou est un programme OPM. Dans la Figure 1 , la procédure P1 est la limite de contrôle.

Figure 1 : Percolation de la pile d'appels et des messages d'exception

Dans OPM, le message d'exception est associé au programme qui est actif sur la pile d'appels. Si l'exception n'est pas traitée par les gestionnaires d'exceptions associés, une vérification de fonction est envoyée à la même entrée de la pile d'appels qui a reçu l'exception. S'il reste non géré, l'entrée est supprimée et la vérification de la fonction est percolée. Le processus se répète jusqu'à ce que l'exception soit traitée.

Dans ILE, un message d'exception est associé à la procédure qui est active sur la pile d'appels. Lorsque l'exception est percolée, elle n'est pas convertie en vérification de fonction. Chaque poste de pile d'appels a la possibilité de traiter l'exception d'origine jusqu'à ce que la limite de contrôle soit atteinte. Ce n'est qu'à ce moment-là que l'exception est convertie en contrôle de fonction, auquel cas le traitement de l'exception recommence à zéro en commençant par la procédure qui a reçu l'exception. Cette fois, chaque poste de liste d'appels a la possibilité de gérer la vérification de la fonction. Si la limite de contrôle est atteinte et que l'exception n'est toujours pas traitée, un message d'exception d'échec générique CEE9901 est envoyé à l'appelant de la procédure à la limite de contrôle. En outre, tout poste de liste d'appels qui ne permettait pas de traiter le message est supprimé.