.NET Global gestionnaire d'exception dans l'application de la console

Question: je veux définir un gestionnaire global d'exception pour les exceptions non gérées dans mon application console. Dans asp.net on peut définir un en mondial de.asax, et dans les applications windows /services, on peut définir comme ci-dessous

AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyExceptionHandler);

Mais comment puis-je définir un gestionnaire global d'exception pour une application console ?

currentDomain semble ne pas fonctionner (.NET 2.0) ?

Edit:

Argh, erreur stupide.

Dans VB.NET, on doit ajouter le "AddHandler" mot-clé devant currentDomain, ou sinon, on ne voit pas le UnhandledException événement dans IntelliSense...

C'est parce que le VB.NET et C# compilateurs traiter la gestion des événements différemment.

InformationsquelleAutor Stefan Steiger | 2010-06-28

.net c#console-application exception-handling vb.net

272

Non, c'est la façon correcte de le faire. Cela a fonctionné exactement comme il se doit, quelque chose que vous pouvez travailler à partir peut-être:
```
using System;

class Program {
    static void Main(string[] args) {
        System.AppDomain.CurrentDomain.UnhandledException += UnhandledExceptionTrapper;
        throw new Exception("Kaboom");
    }

    static void UnhandledExceptionTrapper(object sender, UnhandledExceptionEventArgs e) {
        Console.WriteLine(e.ExceptionObject.ToString());
        Console.WriteLine("Press Enter to continue");
        Console.ReadLine();
        Environment.Exit(1);
    }
}
```
Ne garder à l'esprit que vous ne pouvez pas attraper le type de fichier et charger les exceptions générées par la gigue de cette façon. Ils se produisent avant que votre méthode main() commence à courir. La capture de ces exige de retarder la gigue, déplacez le risqué de code en une autre méthode et d'appliquer la [attribut methodimpl(MethodImplOptions.NoInlining)] attribuent.
- Argh, erreur stupide, j'ai besoin d'ajouter AddHandler en face de domaine d'application.CurrentDomain à voir "UnhandledException" dans VB.NET...
- J'ai mis en œuvre ce qui vous est proposé ici, mais je ne veux pas quitter l'application. Je veux juste l'enregistrer, et de poursuivre le processus (sans Console.ReadLine() ou toute autre perturbation du déroulement du programme. Mais ce que je reçois est l'exception-relancer encore et encore, et encore.
- Jefri: Vous ne pouvez pas continuer une fois que vous obtenez une exception non gérée. La pile est foiré, et c'est la borne. Si vous avez un serveur, ce que vous pouvez faire dans UnhandledExceptionTrapper est redémarrez le programme avec les mêmes arguments de ligne de commande.
- Cela ne fonctionnera pas dans l'exception est levée dans un autre thread!
- Il est certain qu'elle! Nous ne parlons pas de l'Application.ThreadException de l'événement ici.
- Je pense que la clé de la compréhension de cette réponse et les commentaires en réponse est de réaliser que ce code montre maintenant pour détecter l'exception, mais pas complètement "gérer" comme vous pouvez dans un bloc try/catch où vous avez la possibilité de continuer. Voir mon autre réponse pour plus de détails. Si vous "poignée" à l'exception de cette façon, vous n'avez pas d'option pour continuer à exécuter lorsqu'une exception se produit sur un autre thread. En ce sens, on peut dire que cette réponse n'est pas entièrement "gérer" l'exception, si par "gérer" tu veux dire "processus et de continuer à fonctionner".
- C'est pourquoi il est d'Application.ThreadException ainsi.
- Ne pas mentionner il ya beaucoup de technologies pour s'exécuter dans des threads différents. Par exemple, la Task Parallel Library (TPL) a sa propre façon d'attraper les exceptions non gérées. Donc, en disant: cela ne fonctionne pas pour toutes les situations est une sorte de ridicule, il n'y a PAS un seul endroit fourre-tout pour le tout en C#, mais selon les technologies que vous utilisez, il y a différents endroits, vous pouvez brancher dans.
- Application.ThreadException est pour le formulaire de demande et il n'est pas de travail en application de Console. Facile à tester, il suffit d'assigner une Application.ThreadException de l'événement et de l'appel de la Tâche.Usine.StartNew(() => { throw new Exception("Test");}); et d'événements de l'Application.ThreadException n'est pas déclenché.
- vous avez supprimé la réponse que vous avez un lien. Est-il une raison particulière, par exemple, la réponse est incorrecte? Comme un 10k utilisateur je peux encore le voir et je me demande si l'approche de retarder la Gigue est fondamentalement ok.
InformationsquelleAutor Hans Passant

Si vous avez un seul thread de l'application, vous pouvez utiliser un simple try/catch dans la fonction Principale, cependant, cela ne couvre pas les exceptions qui peuvent être levées en dehors de la fonction Principale, sur d'autres threads, par exemple (comme indiqué dans d'autres commentaires). Ce code montre comment une exception peut entraîner l'application de résilier même si vous avez essayé de le manipuler en Main (notez la façon dont le programme se termine normalement si vous appuyez sur entrée et de permettre l'application de fermer correctement avant de l'exception se produit, mais si vous les laissez s'exécuter, il se termine assez malheureusement):

static bool exiting = false;

static void Main(string[] args)
{
   try
   {
      System.Threading.Thread demo = new System.Threading.Thread(DemoThread);
      demo.Start();
      Console.ReadLine();
      exiting = true;
   }
   catch (Exception ex)
   {
      Console.WriteLine("Caught an exception");
   }
}

static void DemoThread()
{
   for(int i = 5; i >= 0; i--)
   {
      Console.Write("24/{0} =", i);
      Console.Out.Flush();
      Console.WriteLine("{0}", 24 / i);
      System.Threading.Thread.Sleep(1000);
      if (exiting) return;
   }
}

Vous pouvez recevoir une notification lorsque un autre thread déclenche une exception pour effectuer certaines nettoyer avant de l'application se ferme, mais aussi loin que je peux dire, vous ne pouvez pas, à partir d'une application console, la force de l'application de continuer à courir, si vous ne la manipulez pas l'exception sur le fil à partir de laquelle il est jeté, sans l'aide de quelque obscur de compatibilité des options pour rendre l'application de se comporter comme il aurait avec des .NET 1.x. Ce code montre comment le thread principal peut être notifié des exceptions venant d'autres threads, mais toujours mettre fin à l'malheureusement:

static bool exiting = false;

static void Main(string[] args)
{
   try
   {
      System.Threading.Thread demo = new System.Threading.Thread(DemoThread);
      AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
      demo.Start();
      Console.ReadLine();
      exiting = true;
   }
   catch (Exception ex)
   {
      Console.WriteLine("Caught an exception");
   }
}

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
   Console.WriteLine("Notified of a thread exception... application is terminating.");
}

static void DemoThread()
{
   for(int i = 5; i >= 0; i--)
   {
      Console.Write("24/{0} =", i);
      Console.Out.Flush();
      Console.WriteLine("{0}", 24 / i);
      System.Threading.Thread.Sleep(1000);
      if (exiting) return;
   }
}

Donc, à mon avis, la meilleure façon de le gérer dans une application console est de veiller à ce que chaque thread dispose d'un gestionnaire d'exception au niveau de la racine:

static bool exiting = false;

static void Main(string[] args)
{
   try
   {
      System.Threading.Thread demo = new System.Threading.Thread(DemoThread);
      demo.Start();
      Console.ReadLine();
      exiting = true;
   }
   catch (Exception ex)
   {
      Console.WriteLine("Caught an exception");
   }
}

static void DemoThread()
{
   try
   {
      for (int i = 5; i >= 0; i--)
      {
         Console.Write("24/{0} =", i);
         Console.Out.Flush();
         Console.WriteLine("{0}", 24 / i);
         System.Threading.Thread.Sleep(1000);
         if (exiting) return;
      }
   }
   catch (Exception ex)
   {
      Console.WriteLine("Caught an exception on the other thread");
   }
}

TRY CATCH ne fonctionne pas en mode de lancement pour des erreurs inattendues :/

InformationsquelleAutor BlueMonkMN

12

Vous devez également gérer les exceptions de threads:
```
static void Main(string[] args) {
Application.ThreadException += MYThreadHandler;
}

private void MYThreadHandler(object sender, Threading.ThreadExceptionEventArgs e)
{
    Console.WriteLine(e.Exception.StackTrace);
}
```
Whoop, désolé c'était pour winforms, pour tous les threads dans une application console, vous devrez les placer dans un bloc try/catch. Threads d'arrière-plan qui rencontre les exceptions non gérées ne pas entraîner l'application à la fin.

InformationsquelleAutor BlackICE
-13

Ce que vous essayez devrait fonctionner selon la doc MSDN pour .Net 2.0. Vous pouvez également essayer un try/catch droite dans main autour de votre point d'entrée pour l'application console.
```
static void Main(string[] args)
{
    try
    {
        //Start Working
    }
    catch (Exception ex)
    {
        //Output/Log Exception
    }
    finally
    {
        //Clean Up If Needed
    }
}
```
Et maintenant votre catch gérer tout ce qui n'est pas pris (dans le thread principal). Il peut être gracieuse et même redémarrer où il a été si vous le souhaitez, ou vous pouvez simplement laisser le soft de mourir et le journal de l'exception. Vous woul ajouter un enfin, si vous vouliez faire un nettoyage. Chaque fil doit être de haut niveau, la gestion des exceptions similaires à la main.

Modifié afin de clarifier le point à propos des threads comme l'a souligné BlueMonkMN et présentés en détail dans sa réponse.
- Des Exceptions peuvent encore être jeté en dehors de la fonction main() de bloc, malheureusement. Ce n'est pas réellement un "catch all" comme vous pourriez le penser. Voir @Hans réponse.
- D'abord je l'ai dit, la façon dont il le fait est correct, et qu'il pouvait essayer un try/catch dans la main. Je ne suis pas sûr de savoir pourquoi vous(ou quelqu'un d'autre) m'a donné un vote vers le bas quand j'étais d'accord avec Hans simplement de donner une autre réponse que je ne m'attendais pas à obtenir un vérifier. Ce n'est pas vraiment juste, et de là à dire que l'alternative est mauvais, sans fournir aucune preuve quant à la façon d'une exception qui peut être pris par le domaine d'application UnhandledException processus qu'un try/catch en Principal ne peut pas attraper. Je trouve ça impoli de dire quelque chose de mal sans le démontrer pourquoi il est mal, il suffit de dire qu'il en est ainsi, ne pas faire en sorte.
- Il est assez évident que vous venez de downvoted 4 de mes anciens posts de 2009 en guise de représailles. Envisager l'édition de votre message et je vais annuler ma downvote (et vous devez annuler votre rage-downvotes vous m'avez donné, je vais faire la même chose).
- Comment puis-je le changer puisque vous n'avez pas fourni la preuve que je dit quoi que ce soit invalide ou méritant une baisse de vote. Je ne suis pas sûr de ce qu'il deviendrait. Donc, je peux le modifier pour le modifier de sorte que vous pouvez annuler la vôtre, et si vous me dites ce que d'autres de la mine vous vers le bas voté, je peux le modifier aussi bien. Une fois vos votes ont été supprimé et que vous modifiez la vôtre, je vais enlever le mien.
- J'ai posté l'exemple que vous demandez. S'il vous plaît être responsable et supprimer votre pertinence en bas de votes de la part de Mike vieux réponses, si vous ne l'avez pas. (Aucun intérêt personnel, n'aime pas voir de tels abus du système.)
- aucune infraction, mais Mike a ramené sur lui-même, j'ai personnellement jamais en bas de vote des gens à moins qu'ils sont en train d'être un idiot complet ou de violation des règles. J'ai l'habitude de laisser la personne qui a posé la question de faire des commentaires et de laisser la place un système de vote en règle avec la vérification de la réponse utilisés par la personne qui a posé la question. Pour juste en bas de voter une réponse de quelqu'un de vraiment essayer de les aider, est tout simplement un trou pour aucune raison. Des gens comme ça ne devrait pas être autorisé à sortir avec elle, de sorte qu'il semblait que juste en bas de voter pour simplement essayer d'aider les autres.
- Pourtant, vous avez encore jouer le même "jeu", il n', seulement d'une manière encore pire parce que c'est de la pure représailles, ne reposant pas sur la qualité d'une réponse. Ce n'est pas un moyen de résoudre le problème, seulement de le rendre pire. Il est particulièrement mauvais quand vous venger de quelqu'un qui a même eu un souci légitime de votre réponse (comme je l'ai démontré).
- Oh, je voudrais également ajouter que le bas-droit de vote n'est pas prévu pour les personnes qui sont "d'être un idiot complet ou viole les règles", mais plutôt de juger de la qualité d'une réponse. Il me semble que vers le bas-droit de vote des réponses afin de "commentaire" sur la personne de leur fournir un beaucoup plus grand abus que vers le bas-droit de vote des réponses basées sur le contenu de la réponse elle-même, indépendamment de savoir si ce vote est exact ou pas. Ne prenez pas/faire de manière personnelle.
- Grâce BlueMonkMN pour la fourniture d'un exemple. Gnome, j'ai upvoted plusieurs de vos vieux accepté les réponses à d'autres questions de la trêve. Envisager de faire de même pour moi.
- Je vais jusqu'voter pour contrer le bas.
- et @Mike, je voudrais revenir à ma réponse et de le défendre avec le fait que les normes pratiques pour une application console est de TOUJOURS avoir try/catch dans la main. Qu'il n'existe qu'un petit nombre de domaine d'application des exceptions qui peuvent ne pas être pris par les principaux try/catch et doivent être gérés par l'intermédiaire de la UnhandledException option. @Blue votre expliquer n'est pas un très bon parce que vous ne suivez pas la bonne conception pour ne pas le piégeage des exceptions dans les threads que vous créez, puisqu'ils ne peuvent être pris à l'extérieur du filetage.
- Votre déclaration n'est pas claire: voulez-vous dire que je ne suis pas à la suite d'une bonne conception, car l'un de mes exemples avaient un gestionnaire d'exceptions dans chaque thread, ou voulez-vous dire que .NET est mal conçu car il n'existe aucun moyen pour intercepter les exceptions à partir d'autres threads? J'ai montré 3 exemples et décrit le comportement de chacun. Le premier, je crois, correspond à votre exemple, la seconde ajoute le "UnhandledException" gestionnaire et qui décrit son comportement, et la dernière montre ce que je considère comme "bonne" gestion des exceptions dans les cas où vous avez plusieurs threads dans une application console. Il ya quelque chose que j'ai raté?
- Que vous êtes en soulignant que chaque thread a besoin de son propre gestionnaire d'exception. Ce serait un try/catch à l'intérieur au début du thread. Ce que je suppose que je suis en train de dire, c'est que nous sommes d'accord sur le bon comportement, mais une raison quelconque vous êtes en désaccord avec moi. Je parlais d'une application console simple que la question n'est pas précise rien sur les threads. Vous allez à la supplémentaires en cas de coin qui comprend les threads. Vous acceptez que try/catch est la bonne façon de le faire et pas avec UnhandledException (si j'ai bien compris).
- Mise à jour de la réponse à préciser ce point, pour ceux qui pensent que je travers la cela permettrait d'intercepter des exceptions dans d'autres threads, même si je n'ai jamais mentionné le filetage ou à la question mentionnée au filetage. 🙂
- LE CHEVAL: IL EST MORT!!!
InformationsquelleAutor Rodney S. Foley

Vous devez vous connecter pour publier un commentaire.