La récupération d’erreurs RPG

Dans deux de mes précédents articles, j’expliquais comment éviter les erreurs de programmation. Pour écrire des programmes sains, il faut apprendre à  s’attendre à  l’inattendu, pour anticiper les problèmes et s’en prémunir. Malheureusement, il n’existe pas de terminal avec boule de cristal. Malgré tous les efforts d’anticipation, des erreurs se produisent. Reste à  savoir où, quand et pourquoi. Mais la présence d’erreurs ne signifie pas que les programmes deviennent inexploitables. Nous allons voir qu’il est possible de redresser la situation, même après des erreurs.
On peut se récupérer après une erreur de programme en utilisant le modèle de traitement des erreurs de l’OS/400 appelé gestionnaire de conditions. Dans cet article, j’explique ce qu’est un gestionnaire de conditions, comment en écrire un simple et comment l’utiliser pour se rétablir après une erreur de programme.

Conditions et gestionnaires
Avec ILE (Integrated Language Environment), IBM a doté l’AS/400 d’un nouveau modèle de traitement des exceptions. Ce modèle repose sur deux éléments : conditions et gestionnaires.
Une condition est un message d’erreur de l’OS/400, défini par une structure de données appelée jeton de condition. Celui-ci contient une représentation, indépendante de la machine, de l’identificateur du message et de sa gravité. Un gestionnaire de conditions est une procédure qui détermine la marche à  suivre face à  une condition.
Comme les gestionnaires de conditions font partie intégrante de l’OS/400, quand un programme rencontre une erreur à  l’exécution, le système d’exploitation appelle son gestionnaire de conditions de premier niveau pour y répondre. Si le gestionnaire de premier niveau ne peut pas régler le problème, l’OS/400 en appelle un autre de deuxième niveau. Si celui-ci est également impuissant, un gestionnaire de troisième niveau est appelé. Si ce dernier ne parvient pas non plus à  résoudre le problème, le système vérifie que l’utilisateur ait défini et enregistré un gestionnaire de conditions. Dans l’affirmative, c’est celui-ci qui est appelé pour déterminer l’action à  mener. Les actions les plus courantes sont les suivantes :

 Reprendre l’exécution du programme défaillant. Le programme ignore que la condition a été générée et l’exécution se poursuit à  l’instruction suivante.
 Transmettre la condition au programme défaillant en envoyant un message d’exception à  sa file d’attente de messages. S’il s’agit d’un programme RPG IV, le message d’exception provoque sa fin anormale, sauf si l’on code dans ce programme une sous-routine de statut de programme (*PSSR, Program Status Subroutine).

L’action de transmission n’a qu’un effet, celui de mettre fin au programme par le système standard de traitement des erreurs du RPG. C’est l’action de reprise du programme qui fournit les moyens nécessaires pour redresser la situation après erreurs. Nous allons donc examiner un gestionnaire de conditions simple pour comprendre son principe de fonctionnement.