Gestionnaires de conditions ILE

ne dépendent
pas du langage. Cet aspect est important pour deux raisons : cela permet d’écrire
des gestionnaires d’erreurs réutilisables, indépendamment du langage (ou des
langages) ILE utilisés pour l’application et de se concentrer sur un seul modèle
de traitement des exceptions plutôt que sur un spécifique de chaque langage
utilisé par l’application.

Tandis que la commande MONMSG du CL permet de réagir convenablement aux
erreurs, certains HLL (comme le RPG) n’offrent pas un contrôle similaire avec
leurs gestionnaires d’exceptions intégrés. Ce contrôle est nécessaire et les
gestionnaires de conditions le fournissent.

Une condition ILE est la représentation indépendante du système d’une
erreur. Elle a une structure de 12 octets, appelée “ condition token ”,
que le système génère lorsqu’une exception survient. On peut utiliser ce
jeton pour associer la condition à  un message d’exception OS/400. Le jeton
contient des informations comme l’identification du message et sa gravité. Pour
voir la structure complète d’un “ condition token ”, voir le
manuel AS/400 ILE Concepts (SC41-5606).

Un gestionnaire de conditions est une procédure ILE qui prend la main
quand une exception survient, mais si et seulement si on le souhaite ! L’application
détermine le moment où les gestionnaires de conditions sont actifs, en
utilisant des API pour les enregistrer (valider) et les désenregistrer
(invalider). Ce modèle permet de définir différents gestionnaires de
conditions à  différents moments dans une application, différents
gestionnaires de conditions pour différentes instances de la même application,
ou toute combinaison souhaitée. On peut même éviter toute utilisation des
gestionnaires pendant l’exécution d’une application !

Le choix ne se limite pas non plus à  la combinaison des gestionnaires.
C’est vous, et pas le système, qui décidez ce qu’accomplit le code de
traitement des conditions. Vous avez le choix entre

• arrêter l’application

• ignorer les erreurs

• procéder à  des ajustements en fonction des erreurs

• renvoyer le message dans la pile d’invocation

• modifier l’exception

• définir le point auquel l’application reprend
  

Et ce ne sont que
quelques exemples des nombreuses possibilités offertes. Tous ces choix
s’ajoutent aux possibilités de traitement des erreurs, souples et robustes.

Plutôt que de continuer à  chanter les louanges des gestionnaires de
conditions, il vaut mieux en utiliser un dans un exemple simple. Par souci de
concision, je n’ai inclus qu’une fraction des fonctions utilisables. Pour une
explication complète des API de gestion des conditions, reportez-vous à  OS/400
Integrated Language Environment (ILE) CEE APIs (SC41-5861).

Utilisation d’un gestionnaire de conditions.
La figure 1 présente un programme RPG IV utilisant un gestionnaire de
conditions. En A, je définis des prototypes de procédures pour enregistrer et
désenregistrer un gestionnaire de conditions. Je fais cela afin de pouvoir
faire référence aux API CEEHDLR (Register a User-Written Condition
Gestionnaire) et CEEHDLU (Unregister a User-Written Condition Gestionnaire) par
les noms RegCndHdlr et UnRegCndHdlr, plus significatifs, avec le code opération
CallP. L’API CEEHDLR admet trois paramètres : 

• un pointeur de procédure dirigé vers la procédure du gestionnaire de
  conditions

• un pointeur de zone de communication

• un code retour
  

La structure des paramètres
de l’API CEEHDLU est similaire, mais n’utilise pas le pointeur de la zone de
communication.

identifie le gestionnaire de conditions que l’on souhaite
enregistrer pour un programme en positionnant le premier paramètre sur
l’adresse du gestionnaire de conditions. C’est ce que je fais en B sur la figure
1, où je définis le pointeur et l’initialise à  l’adresse de la procédure
CNDHDL. On peut transmettre des informations entre le programme applicatif et le
gestionnaire de conditions en utilisant le second paramètre. Il suffit de
passer un pointeur sur les données que l’on souhaite transmettre au
gestionnaire de conditions. Dans notre exemple, j’ai démontré cela en
utilisant une structure de données (C). Le code retour est facultatif. Il peut
servir à  informer le programme applicatif de la réussite du gestionnaire de
conditions.

Les cartes C de l’exemple de programme commencent par enregistrer le
gestionnaire de condition CNDHDL pour le programme (D). Ce gestionnaire reste
actif jusqu’à  ce qu’il soit désenregistré ou jusqu’à  ce que le système
supprime l’entrée de pile d’appel quand le programme applicatif se termine.
Pour simplifier l’exemple, j’ai omis le paramètre code retour facultatif.
Lorsque vous maîtriserez bien les gestionnaires de conditions, incluez ce paramètre
dans vos applications de production pour vous assurer de la bonne exécution des
gestionnaires.

Ensuite, le programme initialise les sous-zones de la structure de données
qui sert de zone de communication. J’initialise les sous-zones avec mon nom,
simplement pour démontrer que l’on peut en définir librement les valeurs, puis
les vérifier à  leur retour du gestionnaire de conditions, pour déterminer les
éventuelles valeurs renvoyées par le gestionnaire.

Voyons maintenant les erreurs. Nous savons tous que la division par zéro
provoque une fin anormale des programmes RPG, n’est-ce pas ? Observez qu’en E
j’effectue volontairement une division par zéro (les cartes D initialisent la
variable de travail Y à  zéro). A l’exécution de cette instruction, une
exception se produit et CNDHDL prend la main. Dans notre exemple, le
gestionnaire de conditions amène le programme applicatif à  continuer l’exécution
à  l’instruction suivant la division. Ne vous souciez pas des détails pour
l’instant : vous verrez plus loin comment CNDHDL réalise cela.

Ensuite, le programme effectue quelques opérations de type tableau sur
le tableau MyArray. Il charge le premier élément du tableau avec la valeur
"G1". Ensuite, il tente de charger le quatrième élément du tableau
(en F). Or, MyArray est défini avec un maximum de trois éléments. Quand le
programme essaie d’exécuter cette instruction, une exception se produit et
CNDHDL reprend à  nouveau la main. Dans ce cas précis, le programme applicatif,
au lieu de continuer à  l’instruction suivante, se "crashe" ! Vous
verrez aussi plus loin pourquoi cela se produit.

En supposant que le programme continue, il apparaît qu’après le
chargement du troisième élément de MyArray, le programme désenregistre
CNDHDL (G) et se termine. Là  encore, j’omets volontairement le paramètre code
de retour.

Gestionnaire de conditions CNDHDL.
Voyons maintenant le gestionnaire de conditions (figure 2). Souvenez-vous que le
système génère un jeton de condition représentant l’erreur quand une
exception se produit. Les gestionnaires de conditions acceptent ce jeton comme
premier paramètre. J’ai défini une structure de données pour ce jeton, en A.

Les cartes D se poursuivent avec une définition pour la zone de
communication (B) évoquée précédemment. Notez que je définis le pointeur
CommAreaPtr sur lequel est basée la structure de données CommArea. Ce pointeur
constitue le second paramètre de CNDHDL.

Le troisième paramètre est l’action que le système devra exécuter après
être revenu du gestionnaire de conditions. Les trois actions de base sont :
resume, percolate et promote. Pour bien les comprendre, reportez-vous à  leur
documentation. L’exemple n’utilise que l’option resume et l’une des options
percolate. Les cartes D, en C, définissent les zones utilisées pour le paramètre
d’action.

CNDHDL est conçu pour ignorer uniquement les erreurs de division par zéro.
En D, la procédure examine les zones préfixe et identique du message du jeton
de condition, pour déterminer si l’erreur résulte d’une division par zéro (le
message RNX0102 signe cela). Dans l’affirmative, la procédure met à  jour une
zone dans la zone de communication et positionne la zone d’action de sorte que
le programme applicatif reprenne à  l’instruction suivant l’erreur. Le programme
peut consulter la zone de communication mise à  jour si tel est le désir du
programmeur.

Quand CNDHDL rencontre une condition autre qu’une division par zéro, la
portion de code située au point E s’exécute. Dans ce cas, la procédure
positionne la zone d’action de sorte que l’exception soit filtrée (percolated)
vers le haut de la pile d’appel. C’est la section du code qui s’exécute quand
notre programme de test génère une exception sur l’opération de tableau
invalide. La percolation provoque la fin anormale du programme de test.

Les gestionnaires de conditions ont beaucoup d’autres fonctions que
celles que je vous ai montrées. Sans oublier une foule d’API de gestion de
conditions supplémentaires permettant de construire des gestionnaires
d’exceptions extrêmement robustes. Après avoir digéré les exemples donnés
ici, prenez connaissance des autres fonctions dans le manuel OS/400
Integrated Language Environment (ILE) CEE APIs et ILE RPG for AS/400
Programmer’s Guide (SC09-2507).