par Gary Guthrie
Passez en revue
les possibilités de traitement des exceptions en RPG. Et voyez comment les
gestionnaires de conditions et d'annulation de ILE pallient certaines des
limitations du RPG/400Dring . . . dring .
. . .
"Informatique.
Francis à l'appareil."
"Salut,
Francis. C'est André du Service Financier. Un message d'erreur est apparu sur
mon terminal il y a quelques instants, et maintenant plus rien ne fonctionne
correctement !"
D'une
voix calme, Francis demande, "Quel était ce message ?"
"Quelque
chose à propos d'un fichier ayant quelque chose, ou quelque chose de ce genre,
je pense" répond André avec confiance.
"Pas
de problème, je m'en occupe" répond Francis. Puis elle raccroche le téléphone
et murmure "Bien, bien".
Vous avez sûrement
déjà entendu çà , n'est-ce pas ? Heure après heure et franc après franc,
les ressources de l'informatique s'amenuisent dès lors que les programmeurs
consacrent un temps précieux aux réparations, après le crash d'une
application. Or, on peut éviter les coûts et les migraines entraînés
par les problèmes applicatifs, en plaçant le traitement des exceptions en tête
de la liste des considérations en matière de conception d'applications.
Il existe de nombreux types d'exceptions et leurs techniques de
traitement diffèrent en fonction de leur type, du langage utilisé, et du
l'environnement modèle de programme (OPM et EPM vs ILE). Je classerai donc les
exceptions en trois groupes distincts :
-
Exceptions
concernant les fichiers. Il s'agit d'erreurs, comme les I/O sur des fichiers
non encore ouverts, des types d'enregistrement indéfinis, des erreurs de
programmes triggers et des erreurs d'unités.
-
Exceptions
concernant les programmes applicatifs. Ce sont des exceptions comme des
erreurs d'index de tableaux invalides, les divisions par zéro et les
erreurs lors de l'appel de sous-programmes. La liste des erreurs de
programmes possibles est énorme.
-
Exceptions
associées au système. Il s'agit d'événements comme des défaillances de
lignes de communications, des programmes annulés par les utilisateurs et
une défaillance du code du système d'exploitation.
Le plus souvent, des techniques de coding appropriées empêchent ces
exceptions de provoquer des fins anormales. Les exceptions associées au système
sont les plus délicates, parce qu'on les maîtrise parfois fort peu au niveau
applicatif. Il est ainsi impossible d'écrire un code suffisamment parfait pour
qu'il évite toute erreur du système d'exploitation.
Quant aux langages évolués (HLL), chacun d'entre eux possède ses
propres mécanismes de traitement des erreurs. Le CL par exemple, utilise
abondamment la commande MONMSG (Monitor Message) pour piéger les exceptions.
Les gestionnaires d'exceptions du RPG comportent des indicateurs d'erreur ou
l'extension E sur certai
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.
Les gestionnaires d’exceptions ILE permettent
de :
-
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
Téléchargez cette ressource
Guide Adobe Firefly, l’IA générative dédiée aux équipes créatives
Depuis plus d’une décennie, Adobe exploite l’intelligence artificielle (IA) pour proposer des solutions toujours plus performantes et innovantes aux équipes créatives. Comment le nouveau moteur d’IA générative Adobe Firefly permet-il aux entreprises de développer leurs capacités créatives et de tirer, dès à présent, tout le profit de l'IA générative ?
