> Tech > Exceptionnels ! Les Gestionnaires d’exceptions du RPG !

Exceptionnels ! Les Gestionnaires d’exceptions du RPG !

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

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 gratuitement cette ressource

    Comment cerner la maturité digitale de votre entreprise ?

    Comment cerner la maturité digitale de votre entreprise ?

    Conçu pour les directions IT et Métiers, ce guide vous permettra d'évaluer précisément vos processus de communication client, d'identifier vos lacunes et points d'inflexion pour établir un plan d’actions capable de soutenir durablement votre évolution. Bénéficiez maintenant d'une feuille de route complète.

    Tech - Par iTPro.fr - Publié le 24 juin 2010