Exceptions non gérées et exécution des blocs finally
3 réponses
ShadowFil
Bonjour,
L'événement AppDomain.UnhandledException est déclenché avant d'exécuter le
bloc finally protégeant l'instruction qui a causé l'erreur, alors que
l'événement Application.ThreadException est appelé après l'exécution du bloc
finally !!!
Dans le premier cas, on peut considérer que le gestionnaire d'exception
abonné à l'événement AppDomain.UnhandledException remplace le bloc catch
inexistant puis exécute le bloc finally, alors que dans le 2ème cas, je ne
comprends pas trop ce qui se passe.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ShadowFil
Lorsqu'une exception se produit, l'exécution s'arrête et le contrôle passe au gestionnaire d'exceptions le plus proche. Le runtime parcourt la pile à la recherche d'un bloc catch avec un filtre capable d'intercepter cette exception, la méthode abonnée à l'événement AppDomain.UnhandledException étant considérée comme le dernier catch avec un filtre acceptant toutes les exceptions. Si aucune méthode n'est abonnée, un gestionnaire par défaut est exécuté par le CLR. Donc, quoi qu'il arrive, il y aura un bloc cacth d'exécuté. Le bloc finally sera donc toujours exécuté après un bloc catch.
Jusque là, tout va bien. Mais ce comportement ne fonctionne plus avec l'événement Application.ThreadException !!!
Si une exception se produit dans un bloc try, le bloc finally est exécuté avant de trouver un gestionnaire d'exception, même un gestionnaire d'exception par défaut du CLR !!! Puisque l'événement Application.ThreadException est déclenché après l'exécution du bloc finally.
Est-ce que quelqu'un pourrait m'expliquer pourquoi ?
Lorsqu'une exception se produit, l'exécution s'arrête et le contrôle passe au
gestionnaire d'exceptions le plus proche. Le runtime parcourt la pile à la
recherche d'un bloc catch avec un filtre capable d'intercepter cette
exception, la méthode abonnée à l'événement AppDomain.UnhandledException
étant considérée comme le dernier catch avec un filtre acceptant toutes les
exceptions. Si aucune méthode n'est abonnée, un gestionnaire par défaut est
exécuté par le CLR. Donc, quoi qu'il arrive, il y aura un bloc cacth
d'exécuté. Le bloc finally sera donc toujours exécuté après un bloc catch.
Jusque là, tout va bien.
Mais ce comportement ne fonctionne plus avec l'événement
Application.ThreadException !!!
Si une exception se produit dans un bloc try, le bloc finally est exécuté
avant de trouver un gestionnaire d'exception, même un gestionnaire
d'exception par défaut du CLR !!! Puisque l'événement
Application.ThreadException est déclenché après l'exécution du bloc finally.
Est-ce que quelqu'un pourrait m'expliquer pourquoi ?
Lorsqu'une exception se produit, l'exécution s'arrête et le contrôle passe au gestionnaire d'exceptions le plus proche. Le runtime parcourt la pile à la recherche d'un bloc catch avec un filtre capable d'intercepter cette exception, la méthode abonnée à l'événement AppDomain.UnhandledException étant considérée comme le dernier catch avec un filtre acceptant toutes les exceptions. Si aucune méthode n'est abonnée, un gestionnaire par défaut est exécuté par le CLR. Donc, quoi qu'il arrive, il y aura un bloc cacth d'exécuté. Le bloc finally sera donc toujours exécuté après un bloc catch.
Jusque là, tout va bien. Mais ce comportement ne fonctionne plus avec l'événement Application.ThreadException !!!
Si une exception se produit dans un bloc try, le bloc finally est exécuté avant de trouver un gestionnaire d'exception, même un gestionnaire d'exception par défaut du CLR !!! Puisque l'événement Application.ThreadException est déclenché après l'exécution du bloc finally.
Est-ce que quelqu'un pourrait m'expliquer pourquoi ?
Julien Bakmezdjian \(MS]
Bonjour,
Quelle exception levez-vous pour tester votre application ? Ce comportement a-t-il lieu avec une exception précise, ou avec tout type d'exceptions dès lors qu'une méthode est abonnée à Application.ThreadException ?
Cordialement,
Julien Bakmezdjian
"ShadowFil" wrote in message news:
Lorsqu'une exception se produit, l'exécution s'arrête et le contrôle passe au gestionnaire d'exceptions le plus proche. Le runtime parcourt la pile à la recherche d'un bloc catch avec un filtre capable d'intercepter cette exception, la méthode abonnée à l'événement AppDomain.UnhandledException étant considérée comme le dernier catch avec un filtre acceptant toutes les exceptions. Si aucune méthode n'est abonnée, un gestionnaire par défaut est exécuté par le CLR. Donc, quoi qu'il arrive, il y aura un bloc cacth d'exécuté. Le bloc finally sera donc toujours exécuté après un bloc catch.
Jusque là, tout va bien. Mais ce comportement ne fonctionne plus avec l'événement Application.ThreadException !!!
Si une exception se produit dans un bloc try, le bloc finally est exécuté avant de trouver un gestionnaire d'exception, même un gestionnaire d'exception par défaut du CLR !!! Puisque l'événement Application.ThreadException est déclenché après l'exécution du bloc finally.
Est-ce que quelqu'un pourrait m'expliquer pourquoi ?
Bonjour,
Quelle exception levez-vous pour tester votre application ? Ce comportement
a-t-il lieu avec une exception précise, ou avec tout type d'exceptions dès
lors qu'une méthode est abonnée à Application.ThreadException ?
Cordialement,
Julien Bakmezdjian
"ShadowFil" <ShadowFil@discussions.microsoft.com> wrote in message
news:8F952433-F61A-4CC6-A960-FEF57199D557@microsoft.com...
Lorsqu'une exception se produit, l'exécution s'arrête et le contrôle passe
au
gestionnaire d'exceptions le plus proche. Le runtime parcourt la pile à la
recherche d'un bloc catch avec un filtre capable d'intercepter cette
exception, la méthode abonnée à l'événement AppDomain.UnhandledException
étant considérée comme le dernier catch avec un filtre acceptant toutes
les
exceptions. Si aucune méthode n'est abonnée, un gestionnaire par défaut
est
exécuté par le CLR. Donc, quoi qu'il arrive, il y aura un bloc cacth
d'exécuté. Le bloc finally sera donc toujours exécuté après un bloc catch.
Jusque là, tout va bien.
Mais ce comportement ne fonctionne plus avec l'événement
Application.ThreadException !!!
Si une exception se produit dans un bloc try, le bloc finally est exécuté
avant de trouver un gestionnaire d'exception, même un gestionnaire
d'exception par défaut du CLR !!! Puisque l'événement
Application.ThreadException est déclenché après l'exécution du bloc
finally.
Est-ce que quelqu'un pourrait m'expliquer pourquoi ?
Quelle exception levez-vous pour tester votre application ? Ce comportement a-t-il lieu avec une exception précise, ou avec tout type d'exceptions dès lors qu'une méthode est abonnée à Application.ThreadException ?
Cordialement,
Julien Bakmezdjian
"ShadowFil" wrote in message news:
Lorsqu'une exception se produit, l'exécution s'arrête et le contrôle passe au gestionnaire d'exceptions le plus proche. Le runtime parcourt la pile à la recherche d'un bloc catch avec un filtre capable d'intercepter cette exception, la méthode abonnée à l'événement AppDomain.UnhandledException étant considérée comme le dernier catch avec un filtre acceptant toutes les exceptions. Si aucune méthode n'est abonnée, un gestionnaire par défaut est exécuté par le CLR. Donc, quoi qu'il arrive, il y aura un bloc cacth d'exécuté. Le bloc finally sera donc toujours exécuté après un bloc catch.
Jusque là, tout va bien. Mais ce comportement ne fonctionne plus avec l'événement Application.ThreadException !!!
Si une exception se produit dans un bloc try, le bloc finally est exécuté avant de trouver un gestionnaire d'exception, même un gestionnaire d'exception par défaut du CLR !!! Puisque l'événement Application.ThreadException est déclenché après l'exécution du bloc finally.
Est-ce que quelqu'un pourrait m'expliquer pourquoi ?
ShadowFil
Voici comment je génère l'exception soit hors de la boucle de message soit dans la boucle de message :
try { Object o = null; o.GetType(); } catch (ArithmeticException e) { // Ce filtre d'interception d'exception n'est pas le bon. Il ne sera donc pas utilisé. string msq = e.Message; MessageBox.Show(...); } finally { MessageBox.Show(...); }
Voici comment je génère l'exception soit hors de la boucle de message soit
dans la boucle de message :
try
{
Object o = null;
o.GetType();
}
catch (ArithmeticException e)
{
// Ce filtre d'interception d'exception n'est pas le bon. Il ne sera donc
pas utilisé.
string msq = e.Message;
MessageBox.Show(...);
}
finally
{
MessageBox.Show(...);
}
Voici comment je génère l'exception soit hors de la boucle de message soit dans la boucle de message :
try { Object o = null; o.GetType(); } catch (ArithmeticException e) { // Ce filtre d'interception d'exception n'est pas le bon. Il ne sera donc pas utilisé. string msq = e.Message; MessageBox.Show(...); } finally { MessageBox.Show(...); }
