Exceptionnels ! Les Gestionnaires d’exceptions du RPG !

Je n’ai jamais beaucoup aimé le traitement des erreurs intégré du RPG. Bien que suffisant aux besoins les plus simples, je ne le considère pas comme acceptable pour autant. Pourtant, c’est la seule technique utilisée dans de nombreuses applications RPG à  l’heure actuelle. En fait, l’application RPG classique ne se sert que d’une partie des possibilités intégrées au RPG. J’aborde brièvement ici le traitement des exceptions spécifique au RPG, mais j’insiste sur le modèle ILE, plus élaboré et moins utilisé.

Au niveau le plus basique, certains codes opération RPG confient à  un indicateur d’erreur le soin de piéger les exceptions concernant des erreurs prévisibles. En cas d’erreur, l’indicateur est allumé et le programme se poursuit à  l’instruction suivante. Pour avoir des détails sur l’erreur, le programme peut examiner le contenu de l’INFDS (file information data structure) pour les exceptions concernant les fichiers, ou la PSDS (program status data structure) pour les exceptions concernant les programmes. Cette solution convient dans certains cas, mais le nombre de codes opération autorisant l’utilisation d’un indicateur d’erreur est limité.

Les extensions E, une nouveauté de la V4R2, peuvent être assimilées à  des indicateurs d’erreur car elles ne sont associées qu’à  un petit nombre de codes opération et ne fonctionnent qu’avec des erreurs prévues. Cette technique définit la valeur de retour pour la fonction intégrée %Status ou %Error quand une erreur se produit. Comme pour les indicateurs d’erreur, on peut consulter la valeur de retour et interroger le contenu de l’INFDS ou de la PSDS.

Dans le cas de sous-routines d’erreur écrites par l’utilisateur (INFSR et *PSSR), les choses se compliquent parce que les règles sont différentes selon qu’il s’agit de procédures principales ou de sous-procédures. Quand une exception survient dans la procédure principale et qu’un indicateur d’erreur ou l’extension E ne la piège pas, le RPG passe la main à  la sous-routine d’erreur utilisateur appropriée, si elle existe. La sous-routine d’erreur INFSR prend la main quand une exception d’I/O se produit, et la sous-routine d’erreur *PSSR prend la main lorsque survient une exception concernant un programme.

On peut confier n’importe quelle action à  ces sous-routines. En principe, on leur demande d’examiner le contenu de l’INFDS ou de la PSDS et de réagir en conséquence. Les sous-routines permettent également d’indiquer le point de retour en fin de sous-routine. Malheureusement, les points de retour possibles sont si limités qu’ils présentent souvent peu d’intérêt. En particulier, on ne peut pas définir un point de retour permettant la poursuite du programme à  l’instruction suivant celle qui contient l’erreur. Pour être honnête au sujet de l’INFSR et de la *PSSR, il faut reconnaître que leurs points de retour possibles étaient plus utiles quand on programmait le RPG dans le cycle RPG et avec des fichiers en entrée primaire. Dès lors qu’on s’est éloigné de ce type de traitements, ces sous-routines ont perdu de leur utilité.

Si une sous-routine d’erreur écrite par l’utilisateur n’est pas présente, le gestionnaire d’exceptions par défaut du RPG prend la main. La réception d’un message d’interrogation par l’utilisateur est le résultat classique de l’action du gestionnaire par défaut.

Lorsqu’une exception se produit dans une sous-procédure et qu’un indicateur d’erreur ou que l’extension E ne la piège pas, on peut utiliser la sous-routine *PSSR. Toutefois, ni la sous-routine INFSR ni le gestionnaire par défaut ne sont disponibles. Les règles de la *PSSR diffèrent pour les sous-procédures, en ce qu’il n’est pas possible de définir un point de retour pour la sous-routine. Quand on atteint l’instruction ENDSR de la *PSSR, la sous-procédure se termine anormalement, et l’appelant de la sous-procédure reçoit le message RNX9001. On peut aussi choisir d’indiquer une valeur de retour. Notons que la *PSSR est propre à  la procédure dans laquelle elle est codée.

Vous commencez certainement à  comprendre pourquoi le traitement des erreurs intégré du RPG ne m’enthousiasme pas. Toutefois, chacune des techniques de traitement des erreurs intégrées dans le RPG a sa place. Ainsi, quand il n’est pas nécessaire d’expliciter une erreur, la technique de l’indicateur ou de l’extension E est souvent suffisante. En outre, si l’on veut simplement fermer une application dans les règles quand une erreur survient, l’INFSR ou la *PSSR conviennent. Bien sûr, on peut utiliser l’INFSR et la *PSSR de nombreuses manières différentes. Toutefois, j’estime que les gestionnaires d’exceptions ILE sont souvent préférables.

• Pallier les limitations du traitement des exceptions en RPG/400

• Contrôler ce qui se passe face à  une exception

• Offrir des modèles de traitement d’erreurs homogènes entre
  tous les langages ILE

• Fermer harmonieusement des applications terminées