La manipulation des exceptions non gérées problème

Je voulais mettre quelques gestionnaire pour toutes les exceptions inattendues que je n'aurais pas pris à l'intérieur de mon code. Dans Program.Main() j'ai utilisé le code suivant:

AppDomain.CurrentDomain.UnhandledException
    += new UnhandledExceptionEventHandler(ErrorHandler.HandleException);

Mais cela n'a pas fonctionné comme je l'espérais. Quand j'ai commencé à l'application en mode de débogage et a jeté une exception, elle a fait appel du gestionnaire, mais par la suite, l'exception aide dans Visual Studio sauté vers le haut comme si l'exception s'est produite sans aucune manipulation. J'ai essayé de l'Application.Exit() dans le gestionnaire mais il ne fonctionne pas ainsi.

Ce que je voudrais, c'est que l'exception est gérée avec mon gestionnaire, puis l'application se ferme bien. Est-il un autre moyen de le faire ou suis-je à l'aide du code ci-dessus dans le mauvais sens?

InformationsquelleAutor agnieszka | 2009-01-02
  1. 29

    C'est parce que vous êtes en cours d'exécution à travers Visual Studio en mode de Débogage. Si vous relâchez et installer votre application quelque part d'autre, rien d'autre que votre gestionnaire global d'exception seront traitées.

    InformationsquelleAutor Peter Lindholm
  2. 34

    Normalement, j'utilise quelque chose comme ça pour essayer d'attraper tous les imprévus de haut-niveau exceptions.

    using System;

static class Program
{
  [STAThread]
  static void Main(string[] argv)
  {
    try
    {
      AppDomain.CurrentDomain.UnhandledException += (sender,e)
      => FatalExceptionObject(e.ExceptionObject);

      Application.ThreadException += (sender,e)
      => FatalExceptionHandler.Handle(e.Exception);

      //whatever you need/want here

      Application.Run(new MainWindow());
    }
    catch (Exception huh)
    {
      FatalExceptionHandler.Handle(huh);
    }
  }

  static void FatalExceptionObject(object exceptionObject) {
    var huh = exceptionObject as Exception;
    if (huh == null) {
      huh = new NotSupportedException(
        "Unhandled exception doesn't derive from System.Exception: "
         + exceptionObject.ToString()
      );
    }
    FatalExceptionHandler.Handle(huh);
  }
}

    Peut-être que c'est quelque chose que vous trouverez utile aussi? Ce code de la route tous les trois façons d'attraper inattendu de haut niveau exceptions au moyen d'un appel de méthode. Tous vous avez besoin maintenant est une classe statique FatalExceptionHandler qui comprend votre haut-niveau de la gestion des exceptions dans ses Handle méthode.

    Et vraiment, tout développeur d'application sait qu'il ya vraiment seulement deux choses à faire:

    1. Afficher/enregistrer l'exception comme bon vous semble
    2. Assurez-vous de quitter/tuer le processus de demande

    Si vous pensez point deux est étrange, n'oubliez pas que nous ne vous embêtez pas à le faire, en premier lieu pour des situations exceptionnelles. Ces choses sont probablement des bugs qui ont besoin de modifier votre application pour être correctement traitée. Tout autre traitement d'exception - la fonctionnelle de type doit être inférieure vers le bas à l'intérieur de votre programme, la capture de certains types d'exceptions où cela fait sens et leur manipulation dans le sens. Autre chose doit proposer à votre FatalExceptionHandler à faire connaître et d'arrêter la peut-être paralysé programme de travail de l'état corrompu

    Morts programmes dites pas de mensonges... 😉

    • +1 pour les Morts des programmes de dire pas de mensonges... 😉
    • Comme vous pouvez le voir à partir de ce Pourquoi est-UnhandledExceptionEventArgs.ExceptionObject un objet et non pas une Exception? post, peut être imprudent de jeter e.ExceptionObject à Exception sans vérifier d'abord, comme il ne sera pas toujours être de type Exception... pourrait aboutir à la création d'une nouvelle Exception ici.
    • Demandé pourquoi il était l'objet, mais n'a jamais vraiment regardé cette. J'ai appris quelque chose de nouveau aujourd'hui. Merci! Va changer de répondre à essayer de remédier à cela.
    • Pas d'accord ici, au moins pour une application interactive avec une utilisation correcte de l'essayer...enfin...les blocs catch. Dans ce cas c'est une idée terrible pour mettre fin à l'application. Tous les une exception non gérée signifie qu'une exception à la boucle principale du programme, qui est en fait assez normal, à moins que l'on met en œuvre des gestionnaires sur chaque gestionnaire d'événements partout. Même si c'est votre politique, ce qui n'est pas très SEC, vous allez oublier l'un et la cause de votre app crash plutôt que de simplement afficher un message.
    • Tu m'as eu sur la dernière ligne...
    InformationsquelleAutor peSHIr
  3. 8

    Noter que les exceptions non gérées sont encore assez fatale; vous ne pouvez vraiment l'utiliser pour l'exploitation forestière, ou peut-être que certains hâtives fermer. Ni ceci, ni Application.ThreadException peut être utilisé comme un mondial de l'évier pour les erreurs.

    La meilleure approche consiste à ajouter une manipulation correcte - par exemple, autour de l'ensemble de votre Main() logique. Notez que même ce ne peut pas attraper quelques exceptions près, telles que les erreurs pendant le chargement du formulaire (qui deviennent particulièrement mauvais, vous pouvez les attraper avec un débogueur, mais pas sans).

    • eh bien, oui, bien sûr, je sais que ça 😉
    • alors pourquoi ne pas les attraper dans main()?
    • "je sais que" c'était une réponse à la "puits pour les" erreurs de la partie. j'ai été enseigné try-catch dans la main est une chose que vous ne devriez pas le faire. cependant, je dois dire honnêtement que je ne sais pas pourquoi ce serait une mauvaise approche (bien sûr, si je peux l'attraper toutes les exceptions, je pense, dans le code)
    InformationsquelleAutor Marc Gravell
  4. 2

    Peut-être ce que vous cherchez est Environment.Exit(int errorcode)

    InformationsquelleAutor Yariv
  5. 0

    Ce comportement est par la conception.

    Mais il y est un travail autour de.

    Soit vous appelez Process.GetCurrentProcess().Kill(); dans le gestionnaire, ou tout simplement ne pas laisser le gestionnaire de fin.

    Découvrez l'exemple:

    class Program
{
    void Run()
    {
        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

        Console.WriteLine("Press enter to exit.");

        do
        {
            (new Thread(delegate()
            {
                throw new ArgumentException("ha-ha");
            })).Start();

        } while (Console.ReadLine().Trim().ToLowerInvariant() == "x");


        Console.WriteLine("last good-bye");
    }

    int r = 0;

    void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Interlocked.Increment(ref r);
        Console.WriteLine("handled. {0}", r);
        Console.WriteLine("Terminating " + e.IsTerminating.ToString());

        Thread.CurrentThread.IsBackground = true;
        Thread.CurrentThread.Name = "Dead thread";            

        while (true)
            Thread.Sleep(TimeSpan.FromHours(1));
        //Process.GetCurrentProcess().Kill();
    }

    static void Main(string[] args)
    {
        Console.WriteLine("...");
        (new Program()).Run();
    }
}

    Cela ne devrait pas être un défaut de l'évier pour les exceptions, sûrement.

    Mais cela devrait être fait pour rendre compte des exceptions gracieusement.

    InformationsquelleAutor bohdan_trotsenko