> Tech > Une exception dans un handler

Une exception dans un handler

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

quand une exception est créée dans un handler, soit par un problème avec une instruction du handler, soit par une instruction Resignal (ou Signal). Quand une exception est créée dans un handler, le SQL runtime cherche d'abord un handler correspondant déclaré dans le handler qui contient l'instruction créatrice de l'exception.

Une exception dans un handler

Considérons le cas de la figure 5,
où une exception SqlState « 42704 » se
produit sur une instruction Update et
cause l’exécution du handler H1.
Ensuite, une exception (E) se produit
dans (H1). Si un handler d’exception
correspondant pour E (H2) existe dans
H1 (c’est-à -dire, est déclaré dans l’instruction
composée de H1), H2 est exécuté.
Si H2 est un handler Continue et s’il s’exécute avec succès, le flux continue
par l’instruction suivante dans H1
(c’est-à -dire C en figure 5). Dans cet
exemple, H1 s’exécute ensuite correctement
et le flux continue par l’instruction
qui suit le Update.
A l’inverse, si H2 est un handler
Exit (ou Undo) et s’il s’exécute avec
succès, on quitte le bloc contenant H2,
ce qui dans cet exemple revient à  quitter
le handler H1. A noter que H1 est
quitté « avec succès » parce que les
deux exceptions ont été traitées. Et,
comme H1 est un handler Continue, le
flux continue par l’instruction après le
Update.
(Attention ! sachez qu’au moment
de l’écriture de cet article, SPL sur
l’iSeries ne se comportait pas de la
sorte pour un handler Exit imbriqué
dans un autre handler. SPL sur l’iSeries
quitte le bloc (c’est-à -dire, BlockX) qui
contient le handler qui contient le
handler Exit. Une question reste en
suspens sur l’interprétation correcte
du standard ANSI qui, je crois, définit le
comportement comme je l’ai expliqué
ci-dessus. N’omettez pas de consulter
les derniers PTF et la documentation
concernant ce cas particulier.)
Voyons maintenant le cas de la figure
6, où une exception SqlState
« 42704 » se produit sur une instruction
Update et cause l’exécution du handler
H3. Puis une exception « E » se produit
dans H3. Parce qu’il n’y a pas de handler
d’exception correspondant pour E
dans H3, le SPL runtime recherche un
handler dans le bloc le plus à  l’intérieur
(BlockX) qui contient le bloc (BlockY)
qui contient H3. (A noter que les
autres handlers déclarés dans BlockY,
par exemple H2, ne sont pas considérés
dans cette recherche.)
Si un handler Continue (H1) dans
un bloc extérieur pour cette dernière
exception s’exécute avec succès, le flux
continue par l’instruction suivante
dans H3 (c’est-à -dire, C en figure 6).
Une fois H3 exécuté, le flux continue
par l’instruction après le Update.
En revanche, si H1 était un handler
Exit pour cette dernière exception et s’exécutait avec succès, le flux reprendrait
par l’instruction immédiatement
après le délimiteur End de l’instruction
composée contenant H1 (c’est-à -dire,
après End BlockX).
S’il n’y a pas de handler d’exception
correspondant pour (E) dans H3
ou dans aucun bloc extérieur, la routine
sort immédiatement et renvoie
une exception à  l’appelant de la routine.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

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