LINQPad et les exceptions non gérées

Question

Je suis en train de tomber en panne LINQPad4 utilisant l'instruction suivante C#:

new Thread(() => new Thread(() => { throw new Exception(); }).Start()).Start(); 

Une boîte de dialogue d'exception non gérée est affichée, mais le processus ne meurt pas. Je suppose que IsTerminating = true comme dans toutes les UnhandledThreadExceptions ... comment cela empêche-t-il le processus de mourir?

Answer 1

il a un gestionnaire global d'exception pour toutes les exceptions de fil non interface utilisateur ainsi, quelque chose comme ceci dans la méthode principale:

AppDomain.CurrentDomain.UnhandledException += 
     new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); 

il y a aussi d'autres petites choses à faire, bien sûr, plus que d'habitude, le try/attraper autour du Application.Run.

voir un article complet et les détails ici: C# Tutorial - Dealing With Unhandled Exceptions

Edit: hb. essayez de déboguer celui-ci: ;-)

using System; 
using System.Threading; 
using System.Windows.Forms; 

namespace WindowsFormsApplication1 
{ 
    static class Program 
    { 
     [STAThread] 
     static void Main() 
     { 
      Application.EnableVisualStyles(); 
      Application.SetCompatibleTextRenderingDefault(false); 

      AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); 

      new Thread(() => new Thread(() => { throw new ApplicationException("Ciao"); }).Start()).Start(); 

      try 
      { 
       Application.Run(new Form1()); 
      } 
      catch (Exception exc) 
      { 
       System.Diagnostics.Debug.WriteLine(exc.Message); 
      } 
     } 

     static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) 
     { 
      // here catching Unhandled Exceptions 
      System.Diagnostics.Debug.WriteLine(e.ExceptionObject.ToString()); 
     } 
    } 
} 

Answer 2

LINQPad semble non seulement d'exécuter ses requêtes, mais aussi charger ses dépendances au sein de leur propre AppDomain. Si vous créez un nouvel AppDomain au sein de votre application, vous pouvez gérer les exceptions de manière conviviale et recharger/compiler l'application de manière conviviale.

Encore plus intéressant est la façon dont LINQPad gère ses dépendances. Apparemment, ils sont "copiés à l'ombre" lorsqu'ils sont chargés dans ces AppDomains, puisque j'ai une bibliothèque personnalisée que j'ai développée et que je suis capable de faire des changements "à la volée" et LINQPad ne verrouille pas le fichier; à la place, il semble qu'il possède un FileSystemWatcher qui recherche les modifications apportées au fichier, décharge l'AppDomain, puis recharge l'AppDomain avec la nouvelle dépendance. La 'pause' dans l'application après avoir construit une nouvelle bibliothèque puis les nouvelles 'méthodes' que j'ai ajoutées sont maintenant disponibles pour les scripts via intellisense indique que LINQPad est plutôt intelligent lorsqu'il s'agit de scripts et de bibliothèques référencées qui:) non seulement changer; mais b) pourrait le faire s'écraser. Toutefois, vous pouvez toujours utiliser System.Diagnostics.Debugger.Break() si vous voulez vraiment vous amuser. Si vous désactivez l'optimisation de vos scripts dans les propriétés LINQPad, vous pouvez réellement déboguer dans le processus LINQPad, obtenir votre code source dans une fenêtre de débogage Visual Studio, placer des points d'arrêt, parcourir, examiner des variables, etc. 'vos extraits de code créés dans LINQPad. Il y a quelques lignes supplémentaires dans votre script, mais ça en vaut la peine si vous faites de gros scripts/tests dans LINQPad. Ceci est encore l'un des meilleurs outils que j'ai pu trouver pour prototyper, tester un appareil et construire du code C# qui utilise des requêtes LINQ que je peux simplement coller dans des applications avec une sensation relativement facile qu'ils se comporteront comme observé.