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.