La capture d'exception personnalisée en c#

J'ai créé une classe d'exception personnalisée comme ci-dessous

namespace testingEXception
{
    public class CustomException : Exception
    {            
        public CustomException()
        {
        }
        public CustomException(string message)
            : base(message)
        {
        }

        public CustomException(string message, Exception innerException)
            : base(message, innerException)
        {

        }
    }
}

Je me suis lancer une exception à partir d'un autre projet dans la même solution, comme ce

namespace ConsoleApplication1
{
    public class testClass
    {
        public void compare()
        {
            if (1 > 0)
            {
                throw new CustomException("Invalid Code");
            }
        }
    }
}

l'attraper comme ça

    namespace testingEXception
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                testClass obj = new testClass();
                obj.compare();

            }
            catch (testingEXception.CustomException ex)
            {
                //throw;
            }
            catch (Exception ex)
            {
               //throw new CustomException(ex.Message);
            }

            Console.ReadKey();
        }
    }
}

Le problème est, l'exception n'est pas se faire attraper par la première prise, mais au lieu de se faire attraper par la deuxième catch, cours de si le type de l'exception montre CustomException.

ce que vous montrez est correcte et devrait fonctionner. DONC, soit vous ne faites pas ce que vous pensez que vous êtes en train de faire ou ce qui se passe n'est pas ce que vous pensez qu'il se passe. Vérifiez que vous n'avez pas plusieurs CustomException dans différents espaces (VS, ne 'Aller à la définition de" sur le lancer et de le rattraper version de CustomeException)
Avec les "jeter" dans les captures(CustomException) il va re-jeté et être pris par catch(Exception). Est-ce que vous voyez?
sur le débogage, le débogueur n'est pas de s'arrêter sur la première capture,au lieu de s'arrêter sur la deuxième prise.
Ajouter Trace.WriteLine("CustomException"); avant la première throw;. Vous obtiendrez une erreur de compilation si catch(CustomException) a été ignorée en raison de catch(Exception)
Donc, le code que vous avez posté ne pas reproduire le problème, merci de poster le code qui permet à une personne de reproduire le problème. Il a aussi des sons qui CustomException est pas public.

OriginalL'auteur Hataf Moin | 2013-08-14

  1. 1

    Vous avez besoin de fournir plus de détails, le code suivant affiche "CustomException":

    try
{
    throw new CustomException("Invalid code.");
}
catch (CustomException ex)
{
    System.Diagnostics.Trace.WriteLine("CustomException");
    throw;
}
catch (Exception ex)
{
    throw;
}

    Avec la classe suivante:

    public class CustomException : Exception
{
    public CustomException()
    {
    }
    public CustomException(string message)
        : base(message)
    {
    }

    public CustomException(string message, Exception innerException)
        : base(message, innerException)
    {

    }
}

    Mise à jour:

    À l'égard des optimisations et de l'optimisation de loin un throw: cela ne peut pas arriver, parce que tout bloc de code particulier ne peut pas savoir si un appelant vers le haut de la pile pourrait avoir le code pour attraper CustomException. Lancer une exception est un visible effets secondaires et il y a un certain nombre de garanties à la CLI d'assurer que les personnes visibles les effets secondaires restent visibles.

    En outre, try, catch et finally blocs sont des "zones protégées" dans l'interface de ligne-parler. Ces régions sont spéciales en ce que les opérations dans la région "visible" de la les effets secondaires ne peuvent pas avoir leurs visible effets secondaires re-commandé. Pour plus de détails, voir http://lynk.at/qH8SHk et http://lynk.at/pJcg98

    La seule chose que je peux penser est que si les deux blocs seulement relever de l'exception et rien d'autre, alors, selon le optimisations du compilateur utilise, il peut optimiser le premier bloc catch. Je l'ai essayé mais dans une application de test et qu'il n'est pas fait pour moi.
    Compilateur n'a presque maintenant optimisations au sein de l'essayer ou enfin les blocs. Il ne peut certainement pas optimiser loin d'un jet ou d'une prise.
    Je ne pense pas qu'il est. Je pense qu'il y est autre chose et plus de détails sont nécessaires. Peut-être que quelqu'un d'autre a mentionné, il existe un type de conflit ou de quelque chose. Je n'indique que le résultat des deux blocs catch comme il l'écrit, est la même si tout cela n'est à relever de l'exception si le compilateur a été assez intelligent, il POURRAIT être possible d'optimiser la première prise. Le comportement ne change pas. Ne dites pas qu'il fait ou serait.
    Il ne peut pas optimiser l'attraper d'abord, il y a de la CLI de garanties comme les effets secondaires et les exceptions générées par un thread sont visibles dans l'ordre spécifié par le CIL (ecma 335) donc, il ne peut pas optimiser loin d'un jet. Ceci est principalement dû au fait que le code ne peut pas savoir si le code plus haut dans la pile pourrait attraper CustomException et ne peut donc pas simplement arrêter de jeter CustomException.

    OriginalL'auteur Peter Ritchie