Conseil 6 : Utiliser des instructions composites imbriquées avec des gestionnaires

de base »,
juillet-août 2003, et « A l’intérieur du
traitement des erreurs de SPL V5R2 :
Partie 2: Coder une procédure stockée
blindée », octobre 2003 ou www.itpro.
fr ) Pour certains SP, UDF ou triggers,
il n’y aura parfois qu’un petit
nombre d’instructions et on n’aura besoin
que d’un ou deux gestionnaires
de conditions. Dans de tels cas, on
peut coder le SPL comme une instruction
composite unique (c’est-à -dire
que toutes les déclarations et instructions
exécutables sont codées entre
une seule paire Begin/End).
Mais, pour des situations plus complexes,
on aura besoin de gestionnaires
de conditions multiples, y compris
ceux qui ne concernent qu’une
seule instruction, comme Open.
Pendant l’exécution normale (c’est-à dire,
sans aucune exception ou avertissement),
tous les gestionnaires de
conditions codés au niveau extérieur
(c’est-à -dire, principal) sont testés
pour chaque instruction exécutée. Un
tel comportement peut ralentir les
SP, les UDF ou les triggers qui ont
beaucoup d’instructions et un nombre
appréciable de gestionnaires de
conditions.
On pourra alors utiliser des instructions composites imbriquées, comme dans le fragment
de code de la figure 1. Dans cet exemple, un gestionnaire
d’exceptions « générique » est déclaré dans le bloc extérieur
(en A) pour intercepter toute exception non traitée
par un autre gestionnaire d’exceptions. Mais le gestionnaire
d’exceptions pour la condition SqlState ‘42704’ (objet indéfini)
est placé dans un bloc imbriqué en même temps que
l’instruction Update pour laquelle la condition est testée
(en B).
Pour l’exécution normale de l’instruction Update, les
deux conditions seront testées. Mais, pour les instructions situées
hors de BlockX, le gestionnaire de conditions pour
SqlState ‘42704’ ne sera pas testé. Ce mode d’utilisation des
blocs imbriqués présente deux avantages : il est plus efficace
et il organise mieux le code SPL.