Instruction try-finally
L’instruction try-finally
est une extension spécifique à Microsoft qui prend en charge la gestion structurée des exceptions dans les langages C et C++.
Syntaxe
La syntaxe suivante décrit l’instruction try-finally
:
// . . .
__try {
// guarded code
}
__finally {
// termination code
}
// . . .
Grammaire
try-finally-statement
:
__try
compound-statement
__finally
compound-statement
L’instruction try-finally
est une extension Microsoft aux langages C et C++ qui permettent aux applications cibles de garantir l’exécution du code propre up lorsque l’exécution d’un bloc de code est interrompue. Le nettoyage se compose de tâches telles que la désallocation de mémoire, la fermeture de fichiers et la libération des handles de fichiers. L'instruction try-finally
est particulièrement utile pour les routines qui ont plusieurs endroits où un contrôle est effectué pour une erreur qui peut provoquer un retour prématuré de la routine.
Pour obtenir des informations connexes et un exemple de code, consultez try-except
Instruction. Pour plus d’informations sur la gestion des exceptions structurées en général, consultez Gestion des exceptions structurées. Pour plus d’informations sur la gestion des exceptions dans les applications managées avec C++/CLI, consultez Gestion des exceptions sous /clr
.
Remarque
La gestion structurée des exceptions fonctionne avec Win32 pour les fichiers sources C et C++. Toutefois, elle n'est pas conçue spécifiquement pour C++. Vous pouvez vous assurer que votre code est plus portable en utilisant la gestion des exceptions C++. En outre, la gestion des exceptions C++ est plus souple, car elle permet de traiter des exceptions de tout type. Pour les programmes C++, il est recommandé d’utiliser le mécanisme de gestion des exceptions C++ (try
, catch
et throw
les instructions).
L'instruction composée après la clause __try
est la section protégée. L'instruction composée après la clause __finally
est le gestionnaire de terminaisons. Le gestionnaire spécifie un ensemble d’actions qui s’exécutent lorsque la section protégée est terminée, qu’elle quitte la section protégée par une exception (arrêt anormal) ou par arrêt standard (arrêt normal).
Le contrôle atteint une instruction __try
par exécution séquentielle simple (passage). Lorsque le contrôle entre, __try
son gestionnaire associé devient actif. Si le flux de contrôle atteint la fin du bloc try, l'exécution se produit de la façon suivante :
Le gestionnaire de terminaisons est appelé.
Lorsque le gestionnaire de terminaisons se termine, l'exécution reprend après l'instruction
__finally
. Toutefois, la section protégée se termine (par exemple, par le biais d’ungoto
corps protégé ou d’unereturn
instruction), le gestionnaire d’arrêt est exécuté avant que le flux de contrôle se déplace hors de la section protégée.Une
__finally
instruction ne bloque pas la recherche d’un gestionnaire d’exceptions approprié.
Si une exception se produit dans le __try
bloc, le système d’exploitation doit trouver un gestionnaire pour l’exception, ou le programme échoue. Si un gestionnaire est trouvé, tous les __finally
blocs sont exécutés et l’exécution reprend dans le gestionnaire.
Par exemple, supposons qu'une série d'appels de fonction lie la fonction A à la fonction D, comme indiqué dans l'illustration suivante. Chaque fonction a un gestionnaire de terminaisons. Si une exception est levée dans la fonction D et gérée dans A, les gestionnaires de terminaisons sont appelés dans l'ordre suivant à mesure que le système déroule la pile : D, C, B.
Le diagramme commence par la fonction A, qui appelle la fonction B, qui appelle la fonction C, qui appelle la fonction D. Fonction D déclenche une exception. Les gestionnaires d’arrêt sont ensuite appelés dans cet ordre : gestionnaire d’arrêt D, puis C’s, B’s, puis A gère l’exception.
Ordre d’exécution du gestionnaire d’arrêt
Remarque
Le comportement de try-finally est différent de certains autres langages qui prennent en charge l’utilisation de finally
, comme C#. Un seul __try
peut avoir soit, mais pas les deux, de __finally
et __except
. Si les deux doivent être utilisés conjointement, une instruction try-except externe doit entourer l'instruction try-finally interne. Les règles qui spécifient le moment d'exécution de chaque blocs sont également différentes.
Pour la compatibilité avec les versions précédentes, , et sont des synonymes pour __try
, __finally
et __leave
sauf si l’option/Za
du compilateur (Désactiver les extensions de langage) est spécifiée._leave
_finally
_try
Mot clé __leave
Le __leave
mot clé est valide uniquement dans la section protégée d’une try-finally
instruction, et son effet est de passer à la fin de la section protégée. L'exécution continue à la première instruction dans le gestionnaire de terminaisons.
Une goto
instruction peut également sortir de la section protégée, mais elle dégrade les performances, car elle appelle le déroulement de la pile. L’instruction __leave
est plus efficace, car elle n’entraîne pas le déroulement de la pile.
Arrêt anormal
La sortie d’une try-finally
instruction à l’aide de la fonction d’exécution longjmp est considérée comme un arrêt anormal. Il n’est pas conforme de sauter dans une instruction __try
, mais il est conforme d’en sortir. Toutes les __finally
instructions actives entre le point de départ (arrêt normal du __try
bloc) et la destination (le __except
bloc qui gère l’exception) doivent être exécutées. Cela s’appelle un déroulement local.
Si un __try
bloc est prématurément arrêté pour une raison quelconque, y compris un saut hors du bloc, le système exécute le bloc associé __finally
dans le cadre du processus de déroulement de la pile. Dans ce cas, la AbnormalTermination
fonction retourne true
si elle est appelée à __finally
partir du bloc ; sinon, elle retourne false
.
Le gestionnaire d’arrêt n’est pas appelé si un processus est tué au milieu de l’exécution d’une try-finally
instruction.
FIN de la section spécifique à Microsoft
Voir aussi
Écriture d’un gestionnaire de terminaison
Structured Exception Handling (C/C++)
Mots clés
Syntaxe du gestionnaire d’arrêt
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour