Comme on le devine, quand une instruction s'exécute correctement, le flux du programme continue avec l'instruction suivante (qui peut être déterminée par un branchement ou une boucle). Quand une condition survient, le flux d'exécution n'est pas aussi simple. Pour commencer l'explication, voyons ce qui se passe quand une condition d'exception
Flux d’exécution normal et d’exception

se produit.
Prenons un cas simple où une instruction
SQL Update qui n’est pas un
handler cause une exception, comme
SqlState « 42704 ». Le SQL runtime recherche
d’abord la présence d’un
handler pour la condition spécifique
(c’est-à -dire, SqlState « 42704 ») dans le
bloc immédiat (c’est-à -dire le plus à
l’intérieur) contenant l’instruction
Update. (Je rappelle que j’utilise
« bloc » comme raccourci de « instruction
composée ».) Si un tel handler
existe, il commence l’exécution. Sinon,
le SQL runtime recherche la présence
d’un handler pour la condition générale
SqlException dans le même bloc
et, s’il le trouve, l’exécute.
Toujours avec cet exemple, si un
handler correspondant est trouvé dans
le même bloc que l’instruction Update,
l’exécution commence avec la première
instruction du handler. Si le
handler n’exécute pas une instruction
Resignal (ou Signal) et si aucune condition
ne survient pour les instructions à
l’intérieur du handler, le handler va
normalement à son terme. Dans un tel
cas, le flux d’exécution dépend du type
de handler, de la manière suivante :
• Handler Continue – L’exécution
continue par l’instruction venant
aussitôt après celle qui a causé l’invocation
du handler (dans ce cas,
l’instruction après le Update). A noter
que dans ce cas simple, l’instruction
qui a causé l’invocation du handler
est aussi celle qui a causé
l’exception initiale.
• Handler Exit – On quitte le bloc
contenant le handler. A noter que
dans cette situation, le même bloc
contient aussi l’instruction incriminée
(dans ce cas, le Update). L’exécution reprend avec l’instruction
qui suit immédiatement le délimiteur
End de l’instruction composée.
• Handler Undo – Premièrement,
une instruction Rollback est exécutée
pour défaire les éventuels changements
effectués par les instructions
précédentes dans le bloc
contenant le handler. Ensuite, l’exécution
reprend de la même manière
que pour un handler Exit. (A noter
qu’une instruction composée doit
indiquer le mot-clé Atomic après le
mot-clé Begin afin de contenir un
handler Undo. Les handlers Undo ne
sont pas autorisés dans des triggers.)
Jusque-là , le flux des handlers est
plutôt simple. Voyons un cas un peu
plus complexe. Si le bloc immédiat ne
contient pas un handler de condition
spécifique ou général correspondant,
le SQL runtime répète la recherche
d’un handler dans le bloc suivant vers
l’extérieur, et ainsi de suite jusqu’au
bloc le plus à l’extérieur de la routine
(ProcBody, par exemple en figure 3), si
nécessaire. Si aucun handler correspondant
n’est trouvé, la routine sort et
la condition est créée pour l’appelant
de la routine.
Si un handler correspondant est
trouvé dans un bloc extérieur, l’exécution
commence par la première instruction
du handler. Si celui-ci n’exécute
pas une instruction Resignal (ou
Signal) et si aucune condition n’apparaît
pour les instructions dans le handler,
celui-ci s’exécute normalement.
Dans ce cas, le flux d’exécution dépend
du type de handler, comme suit :
• Handler Continue – Comme dans le
cas précédent, l’exécution continue
avec l’instruction après celle qui a
causé l’invocation du handler (à nouveau,
dans cet exemple, l’instruction
après le Update).
• Handler Exit – On sort du bloc contenant
le handler. L’exécution reprend
avec l’instruction qui suit immédiatement
le délimiteur End de l’instruc-tion composée contenant le handler.
Cela peut provoquer la sortie de
multiples niveaux inférieurs de blocs
imbriqués, selon le nombre de niveaux
au-dessus de l’instruction incriminée
auquel le handler est déclaré.
• Handler Undo – Tout d’abord, une
instruction Rollback est exécutée
pour défaire les éventuels changements
faits par les instructions antérieures
dans le bloc contenant le
handler. Puis l’exécution reprend
comme pour le handler Exit ci-dessus.
Quelques points sont intéressants
à noter. Quand un handler Continue
s’exécute normalement, l’exécution
reprend toujours avec l’instruction
après celle qui a causé l’invocation du
handler, quel que soit le bloc dans lequel
le handler Continue est déclaré.
(Cela ressemble un peu à un « return »
dans une sous-routine HLL.) A l’inverse,
quand un handler Exit (ou
Undo) se termine normalement, l’exécution
reprend toujours avec l’instruction
après le bloc dans lequel le handler
est déclaré.
Téléchargez cette ressource

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
- Les PME attendent un meilleur accès aux données d’émissions de la part des fournisseurs
- Fraude & IA : Dr Jekyll vs. Mr Hyde, qui l’emporte ?
