L'exception uncatchable, pt 2

Question

Mise à jour: J'ai déposé un rapport de bogue sur Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/details/568271/debugger-halting-on-exception-thrown-inside-methodinfo-invoke#details

Si vous pouvez reproduire ce problème sur votre machine, s'il vous plaît upvote le bug peut donc être réglé!

---

Ok je l'ai fait quelques tests et j'ai réduit le problème à quelque chose de très simple:

i. Créez une méthode dans une nouvelle classe qui lève une exception:

public class Class1 { 
    public void CallMe() { 
     string blah = null; 
     blah.ToLower(); 
    } 
} 

ii. Créez un MethodInfo qui pointe vers cette méthode ailleurs:

Type class1 = typeof(Class1); 
Class1 obj = new Class1(); 
MethodInfo method = class1.GetMethod("CallMe"); 

iii. Enveloppez un appel à Invoke() dans un bloc try/catch:

try { 
    method.Invoke(obj, null); // exception is not being caught! 
} catch { 
} 

iv. Exécutez le programme sans le débogueur (fonctionne bien).

v. Exécutez maintenant le programme avec le débogueur. Le débogueur arrêtera le programme lorsque l'exception se produit, même si elle est enveloppée dans un gestionnaire catch qui essaie de l'ignorer. (Même si vous placez un point d'arrêt dans le bloc catch, il s'arrêtera avant qu'il ne l'atteigne!)

En fait, l'exception se produit lorsque vous l'exécutez sans le débogueur. Dans un projet de test simple, il est ignoré à un autre niveau, mais si votre application a une gestion globale des exceptions, elle se déclenchera également. [voir les commentaires]

Cela me cause un vrai casse-tête, car il maintient le déclenchement de mon gestionnaire d'accident de l'application, sans parler de la douleur, il est de tenter de déboguer.

Answer 1

Je peux reproduire ceci sur mon .NET 4 boîte, et vous avez raison - il se produit seulement sur. NET 4.0.

Cela ressemble beaucoup à un bug pour moi, et devrait aller sur MS Connect. Major si cela gâche votre gestionnaire d'accident. On dirait que c'est une manière non-plaisante de contourner ce problème pour envelopper la méthode invoquée dans son propre gestionnaire. :-(

Une chose que je ne peux pas reproduire, cependant, est le déclenchement du gestionnaire de pannes Voici mon programme:..

namespace trash { 
    public class Class1 { 
     public void CallMe() { 
      string blah = null; 
      blah.ToLower(); 
     } 
    } 

    class Program { 
     static void Main(string[] args) { 
      AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);   
      var class1 = typeof(Class1); 
      var method = class1.GetMethod("CallMe"); 

      try { 
       var obj = new Class1(); 
       method.Invoke(obj, null); // exception is not being caught! 
      } 
      catch (System.Reflection.TargetInvocationException) { 
       Console.Write("what you would expect"); 
      } 

     } 

     static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) { 
      Console.Write("it would be horrible if this got tripped but it doesn't!"); 
     } 
    } 
} 

Answer 2

Vous ne pouvez pas intercepter toutes les exceptions. Il y a quelques hypothèses dans votre exemple. Vous supposez, par exemple, que l'exception a été déclenchée sur le thread appelant. Attraper des exceptions non gérées sur d'autres threads dépend des runtimes que vous utilisez (console, winforms, WPF, ASP.Net, etc.).

En outre, les appels à System.Environment.FailFast() ne génèrent aucune condition de handlable - le processus est effectivement terminé sans aucune possibilité d'intervention.