> 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

État des lieux de la sécurité cloud-native

État des lieux de la sécurité cloud-native

L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.

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