> Tech > Déclaration d’un gestionnaire d’exceptions

Déclaration d’un gestionnaire d’exceptions

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Après les déclarations de variables locales, la procédure déclare un gestionnaire pour la condition SQLException (en D). Ce gestionnaire s'exécute quand SQLState est défini avec une valeur ne commençant pas par 00 (réussite), 01 (avertissement) ou 02 (ligne non trouvée). Quelle que soit la méthode adoptée pour le traitement d'erreurs

Déclaration d’un gestionnaire d’exceptions

SPL, il faut
toujours coder un gestionnaire pour la condition SQLException. Faute de quoi, en
cas d’exception, la procédure cataloguée se terminera de façon anormale.
C’est la seule manière de piéger une exception dans une procédure SQL.

            A
partir de la V4R4, il faut coder exactement une instruction non composite dans
un gestionnaire ; il n’est pas possible d’omettre l’instruction ni
d’utiliser une instruction composite. Au début, le manque actuel de support
des instructions composites imbriquées pourra sembler constituer un obstacle
important, mais la déclaration de gestionnaire en D, figure 1, utilise une “ astuce ”
de programmation SPL utile pour autoriser de multiples instructions de
traitement d’erreurs. Sur le plan technique, le gestionnaire ne comporte
qu’une instruction (la boucle), mais le corps de “ Loop ”
contient trois instructions. Pour utiliser cette technique, on code un label (ExceptionHandler:
par exemple) sur l’instruction Loop et on code un Leave comme dernière
instruction dans le corps de la boucle. Ainsi, les instructions placées dans le
corps de la boucle s’exécutent une fois exactement (notons qu’on doit
utiliser une instruction Loop, pas une instruction While, pour “ imiter ”
une instruction composite dans un gestionnaire, parce que la condition qui est
testée pour une instruction While modifie SQLState avant que les instructions
éventuelles présentes dans le corps de l’instruction While ne s’exécutent.)

            Pour
la technique de traitement d’erreurs décrite ci-dessous, on utilise ce
gestionnaire des exceptions pour capturer le SQLState, positionner la variable
ExceptionState, et poursuivre l’exécution de l’instruction après celle
ayant causé l’exception. Cette méthode permet d’utiliser du code en ligne
pour traiter les trois conditions (normal, avertissement et exception) après
chaque instruction. Par ce procédé, on peut utiliser le même jeu de variables
associées aux erreurs et la même les déclaration de gestionnaire pour toutes
les procédures cataloguées. On peut coder les gestionnaires SPL de multiples
manières. Cependant, à  mon avis, il est beaucoup plus simple et sûr de
n’utiliser que ce gestionnaire et de traiter les résultats d’une
instruction en utilisant un code conditionnel simple pour tester la valeur de
SQLState sauvegardée à  la suite de l’instruction.

Téléchargez cette ressource

Guide des Solutions Cloud & Services Managés Simplifiés

Guide des Solutions Cloud & Services Managés Simplifiés

Comment capitaliser sur son existant tout en bénéficiant, dès à présent, des promesses de flexibilité et de scalabilité du cloud ? Découvrez les bonnes pratiques pour répondre aux défis de simplification du Cloud dans ce nouveau TOP 5.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT