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
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Le trilemme de la souveraineté : le coût caché du cloud qui freine l’IA en Europe
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Semperis : gouverner l’identité à l’ère des agents IA
- Analyse Patch Tuesday Mars 2026
Articles les + lus
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
