La reprise après erreur est d’autant plus rapide que la détection de la condition est précoce

erreur est d’autant plus rapide que la détection de la condition
est précoce. Non seulement les gestionnaires de conditions interviennent après
l’événement, mais ils utilisent aussi des ressources machine abondantes.
Pour mesurer la charge associée à  un gestionnaire de conditions, j’ai écrit deux
versions d’un programme simple qui effectue les calculs de la procédure GetPrfPc
dans le programme de service SlsAnlPrc. Dans chaque programme, les calculs sont
effectués deux fois dans une boucle exécutée 5.000 fois.
Le premier calcul crée une condition de division par zéro. Le second, une condition
de troncature d’ordre supérieur. Le premier programme appelle GetPrfPc pour effectuer
les calculs et utilise ses propres moyens de défense pour éviter les erreurs.
Le second programme inclut les opérations Eval provenant du code en ligne GetPrfPc
et utilise le gestionnaire de conditions pour détecter les erreurs. Le premier
programme s’exécute en une seconde CPU. Il en faut 11 au second. Ces résultats
parlent d’eux-mêmes : les gestionnaires de conditions sont lents. C’est pourquoi
il faut coder défensivement, et ne compter sur eux que pour corriger les erreurs
inattendues occasionnelles.
Les gestionnaires de conditions sont destinés à  résoudre les problèmes, pas à 
les créer. Pourtant, faute du soin et de l’attention nécessaires, ils peuvent
masquer certains problèmes du code et déclencher des boucles sans fin. Supposons
que X ait une longueur d’un chiffre et qu’un gestionnaire de conditions protège
le code suivant :

C Eval X = 1
C DoW X < 10
. . . Faire quelque chose
C Eval X = X + 1
C EndDo

La boucle se comporte bien jusqu’à  ce que X égale 9. A l’itération suivante, 1
est ajouté à  X, résultant en une troncature d’ordre supérieur. X est donc remis
à  0 et la boucle se s’arrête plus. Quand on utilise un gestionnaire de conditions,
il faut toujours penser à  vérifier des erreurs à  des points stratégiques. Cette
version de la boucle aura au moins le mérite de détecter le bogue :

C Eval X = 1
C DoW X < 10
. . . Faire quelque chose
C Eval X = X + 1
C If CndMsgId <> *Blank
. . . Signaler l’erreur
C CallP ClearCnd( CndPtr )
C Leave
C EndIf
C EndDo

Le gestionnaire de conditions simple que j’ai présenté intercepte deux types d’erreurs
: division par zéro et troncature d’ordre supérieur. On peut facilement l’adapter
pour détecter d’autres types. Cependant, il faut bien réfléchir aux types d’erreurs
que le gestionnaire doit détecter et limiter son champ d’action autant qu’on le
peut. Si l’on demande, par exemple, au gestionnaire d’intercepter des erreurs
d’indexage de tableau, on ne fera que masquer des bogues de programmation, parfaitement
évitables en codant défensivement.

Autres articles de cette série

« Style RPG IV : pour écrire un code sain », NEWSMAGAZINE, Septembre 2000.
« Style RPG IV : même l’inattendu peut arriver ! », SYSTEMS Journal, Octobre 2000.

Plongée dans le code de reprise
Utilisés judicieusement, les gestionnaires de conditions parachèvent élégamment
le système défensif d’un programme. Mais ils ne doivent jamais remplacer le coding
défensif. Il est préférable d’utiliser les trois lignes de défense décrites dans
les deux articles précédents. Premièrement, on utilise les fonctions intégrées
et/ou les indicateurs de résultat du RPG pour intercepter les erreurs sur toutes
les opérations supportant ces fonctions. Deuxièmement, on ajoute du code défensif
pour protéger les programmes contre d’autres erreurs courantes, comme la division
par zéro, la troncature d’ordre supérieur et les erreurs d’indexage de tableau.
Troisièmement, on utilise les gestionnaires de conditions pour corriger les erreurs
insolites qui auraient franchi les deux premières lignes de défense.