Attraper plusieurs exceptions à la fois?

Il est déconseillé de simplement attraper System.Exception. Au lieu de cela, seules les exceptions "connues" doivent être interceptées.

Maintenant, cela conduit parfois à un code répétitif inutile, par exemple:

try
{
    WebId = new Guid(queryString["web"]);
}
catch (FormatException)
{
    WebId = Guid.Empty;
}
catch (OverflowException)
{
    WebId = Guid.Empty;
}

Je me demande: existe-t-il un moyen d'attraper les deux exceptions et de ne l' WebId = Guid.Emptyappeler qu'une seule fois?

L'exemple donné est assez simple, car il ne s'agit que d'un GUID. Mais imaginez le code où vous modifiez un objet plusieurs fois, et si l'une des manipulations échoue de la manière attendue, vous voulez "réinitialiser" le object. Cependant, s'il y a une exception inattendue, je veux toujours la jeter plus haut.

Attrapez System.Exceptionet allumez les types

catch (Exception ex)            
{                
    if (ex is FormatException || ex is OverflowException)
    {
        WebId = Guid.Empty;
        return;
    }

    throw;
}

EDIT: Je suis d'accord avec d'autres qui disent que, depuis C # 6.0, les filtres d'exception sont désormais une solution parfaitement adaptée:catch (Exception ex) when (ex is ... || ex is ... )

Sauf que je déteste toujours la mise en page sur une seule ligne et que je présenterais personnellement le code comme suit. Je pense que c'est aussi fonctionnel qu'esthétique, car je pense que cela améliore la compréhension. Certains peuvent être en désaccord:

catch (Exception ex) when (
    ex is ...
    || ex is ...
    || ex is ...
)

ORIGINAL:

Je sais que je suis un peu en retard à la fête ici, mais sainte fumée ...

Aller droit au but, ce type de duplique une réponse antérieure, mais si vous voulez vraiment effectuer une action commune pour plusieurs types d'exceptions et garder le tout propre et bien rangé dans le cadre de la seule méthode, pourquoi ne pas simplement utiliser un lambda / fermeture / fonction en ligne pour faire quelque chose comme ce qui suit? Je veux dire, les chances sont assez bonnes que vous finissiez par réaliser que vous voulez simplement faire de cette fermeture une méthode distincte que vous pouvez utiliser partout. Mais alors il sera super facile de le faire sans réellement changer le reste du code structurellement. Droite?

private void TestMethod ()
{
    Action<Exception> errorHandler = ( ex ) => {
        // write to a log, whatever...
    };

    try
    {
        // try some stuff
    }
    catch ( FormatException  ex ) { errorHandler ( ex ); }
    catch ( OverflowException ex ) { errorHandler ( ex ); }
    catch ( ArgumentNullException ex ) { errorHandler ( ex ); }
}

Je ne peux pas m'empêcher de me demander ( avertissement: un peu d'ironie / sarcasme à venir) pourquoi diable faire tous ces efforts pour remplacer simplement ce qui suit:

try
{
    // try some stuff
}
catch( FormatException ex ){}
catch( OverflowException ex ){}
catch( ArgumentNullException ex ){}

... avec une variation folle de cette odeur de code suivante, je veux dire par exemple, seulement pour prétendre que vous enregistrez quelques touches.

// sorta sucks, let's be honest...
try
{
    // try some stuff
}
catch( Exception ex )
{
    if (ex is FormatException ||
        ex is OverflowException ||
        ex is ArgumentNullException)
    {
        // write to a log, whatever...
        return;
    }
    throw;
}

Parce qu'il n'est certainement pas automatiquement plus lisible.

Certes, j'ai laissé les trois instances identiques /* write to a log, whatever... */ return;du premier exemple.

Mais c'est en quelque sorte mon point. Vous avez tous entendu parler des fonctions / méthodes, non? Sérieusement. Écrivez une ErrorHandlerfonction commune et, comme, appelez-la depuis chaque bloc catch.

Si vous me demandez, le deuxième exemple (avec les mots if- isclés et ) est à la fois beaucoup moins lisible et simultanément beaucoup plus sujet aux erreurs pendant la phase de maintenance de votre projet.

La phase de maintenance, pour toute personne qui pourrait être relativement nouvelle dans la programmation, représentera 98,7% ou plus de la durée de vie globale de votre projet, et le pauvre schmuck qui effectue la maintenance va presque certainement être quelqu'un d'autre que vous. Et il y a de fortes chances qu'ils passent 50% de leur temps au travail à maudire votre nom.

Et bien sûr, FxCop vous aboie et vous devez donc également ajouter un attribut à votre code qui a précisément un lien avec le programme en cours d'exécution, et n'est là que pour dire à FxCop d'ignorer un problème qui, dans 99,9% des cas, est totalement correct en signalant. Et, désolé, je peux me tromper, mais cet attribut "ignorer" ne se compile-t-il pas réellement dans votre application?

Est-ce que mettre l'ensemble du iftest sur une seule ligne le rendrait plus lisible? Je ne pense pas. Je veux dire, il y a longtemps, un autre programmeur a soutenu avec véhémence que mettre plus de code sur une ligne le rendrait "plus rapide". Mais bien sûr, il était complètement fou. Essayer de lui expliquer (avec un visage impassible - ce qui était difficile) comment l'interprète ou le compilateur briserait cette longue ligne en déclarations discrètes d'une instruction par ligne - essentiellement identiques au résultat s'il était allé de l'avant et vient de rendre le code lisible au lieu d'essayer de surpasser le compilateur - n'a eu aucun effet sur lui. Mais je m'égare.

À quel point cela est-il moins lisible lorsque vous ajoutez trois autres types d'exception, dans un mois ou deux? (Réponse: ça devient beaucoup moins lisible).

L'un des points majeurs, en réalité, est que la plupart du point de formatage du code source textuel que nous regardons tous tous les jours est de rendre vraiment, vraiment évident pour les autres êtres humains ce qui se passe réellement lorsque le code s'exécute. Parce que le compilateur transforme le code source en quelque chose de totalement différent et ne se soucie pas du style de formatage de votre code. Donc, tout-en-une-ligne est tout aussi nul.

Je dis juste ...

// super sucks...
catch( Exception ex )
{
    if ( ex is FormatException || ex is OverflowException || ex is ArgumentNullException )
    {
        // write to a log, whatever...
        return;
    }
    throw;
}

Comme d'autres l'ont souligné, vous pouvez avoir une ifdéclaration à l'intérieur de votre bloc catch pour déterminer ce qui se passe. C # 6 prend en charge les filtres d'exception, donc les éléments suivants fonctionneront:

try { … }
catch (Exception e) when (MyFilter(e))
{
    …
}

La MyFilterméthode pourrait alors ressembler à ceci:

private bool MyFilter(Exception e)
{
  return e is ArgumentNullException || e is FormatException;
}

Alternativement, cela peut être fait en ligne (le côté droit de l'instruction when doit simplement être une expression booléenne).

try { … }
catch (Exception e) when (e is ArgumentNullException || e is FormatException)
{
    …
}

Ceci est différent de l'utilisation d'une ifinstruction dans lecatch bloc, l'utilisation de filtres d'exception ne déroulera pas la pile.

Vous pouvez télécharger Visual Studio 2015 pour vérifier cela.

Si vous souhaitez continuer à utiliser Visual Studio 2013, vous pouvez installer le package de nuget suivant:

Install-Package Microsoft.Net.Compilers

Au moment de la rédaction de ce document, cela inclura la prise en charge de C # 6.

Le référencement de ce package entraînera la génération du projet à l'aide de la version spécifique des compilateurs C # et Visual Basic contenus dans le package, par opposition à toute version installée du système.

Pas en C # malheureusement, car vous auriez besoin d'un filtre d'exception pour le faire et C # n'expose pas cette fonctionnalité de MSIL. VB.NET a cependant cette capacité, par exemple

Catch ex As Exception When TypeOf ex Is FormatException OrElse TypeOf ex Is OverflowException

Ce que vous pourriez faire, c'est utiliser une fonction anonyme pour encapsuler votre code d'erreur, puis l'appeler dans ces blocs catch spécifiques:

Action onError = () => WebId = Guid.Empty;
try
{
    // something
}
catch (FormatException)
{
    onError();
}
catch (OverflowException)
{
    onError();
}

Par souci d'exhaustivité, depuis .NET 4.0, le code peut être réécrit comme suit:

Guid.TryParse(queryString["web"], out WebId);

TryParse ne lève jamais d'exceptions et renvoie false si le format est incorrect, en définissant WebId sur Guid.Empty.

Depuis C # 7, vous pouvez éviter d'introduire une variable sur une ligne distincte:

Guid.TryParse(queryString["web"], out Guid webId);

Vous pouvez également créer des méthodes pour analyser les tuples de retour, qui ne sont pas encore disponibles dans .NET Framework à partir de la version 4.6:

(bool success, Guid result) TryParseGuid(string input) =>
    (Guid.TryParse(input, out Guid result), result);

Et utilisez-les comme ceci:

WebId = TryParseGuid(queryString["web"]).result;
// or
var tuple = TryParseGuid(queryString["web"]);
WebId = tuple.success ? tuple.result : DefaultWebId;

La prochaine mise à jour inutile de cette réponse inutile survient lorsque la déconstruction des paramètres externes est implémentée en C # 12. :)

Les filtres d'exception sont désormais disponibles dans c # 6+. Tu peux faire

try
{
       WebId = new Guid(queryString["web"]);
}
catch (Exception ex) when(ex is FormatException || ex is OverflowException)
{
     WebId = Guid.Empty;
}

Dans C # 7.0+, vous pouvez également combiner cela avec la correspondance de motifs

try
{
   await Task.WaitAll(tasks);
}
catch (Exception ex) when( ex is AggregateException ae &&
                           ae.InnerExceptions.Count > tasks.Count/2)
{
   //More than half of the tasks failed maybe..? 
}

Si vous pouvez mettre à jour votre application en C # 6, vous avez de la chance. La nouvelle version C # a implémenté des filtres d'exception. Vous pouvez donc écrire ceci:

catch (Exception ex) when (ex is FormatException || ex is OverflowException) {
    WebId = Guid.Empty;
}

Certaines personnes pensent que ce code est le même que

catch (Exception ex) {                
    if (ex is FormatException || ex is OverflowException) {
        WebId = Guid.Empty;
    }
    throw;
}

Mais ce n'est pas. En fait, c'est la seule nouvelle fonctionnalité de C # 6 qui n'est pas possible d'émuler dans les versions précédentes. Tout d'abord, une relance signifie plus de frais généraux que de sauter le crochet. Deuxièmement, il n'est pas sémantiquement équivalent. La nouvelle fonctionnalité conserve la pile intacte lorsque vous déboguez votre code. Sans cette fonctionnalité, le vidage sur incident est moins utile, voire inutile.

Voir une discussion à ce sujet sur CodePlex . Et un exemple montrant la différence .

Si vous ne souhaitez pas utiliser un if déclaration dans les catchchamps, en C# 6.0vous pouvez utiliser la Exception Filterssyntaxe qui a déjà été pris en charge par le CLR dans les versions des avant - premières , mais n'a existé que dans VB.NET/ MSIL:

try
{
    WebId = new Guid(queryString["web"]);
}
catch (Exception exception) when (exception is FormatException || ex is OverflowException)
{
    WebId = Guid.Empty;
}

Ce code n'attrapera Exceptionque lorsqu'il s'agit d'un InvalidDataExceptionou ArgumentNullException.

En fait, vous pouvez mettre pratiquement n'importe quelle condition à l'intérieur de cette whenclause:

static int a = 8;

...

catch (Exception exception) when (exception is InvalidDataException && a == 8)
{
    Console.WriteLine("Catch");
}

Notez que contrairement à un if instruction à l'intérieur de la catchportée de, Exception Filtersne peut pas lancer Exceptions, et quand ils le font, ou lorsque la condition ne l'est pas true, la catchcondition suivante sera évaluée à la place:

static int a = 7;

static int b = 0;

...

try
{
    throw new InvalidDataException();
}
catch (Exception exception) when (exception is InvalidDataException && a / b == 2)
{
    Console.WriteLine("Catch");
}
catch (Exception exception) when (exception is InvalidDataException || exception is ArgumentException)
{
    Console.WriteLine("General catch");
}

Sortie: prise générale.

Lorsqu'il y en a plus d'un true Exception Filter- le premier sera accepté:

static int a = 8;

static int b = 4;

...

try
{
    throw new InvalidDataException();
}
catch (Exception exception) when (exception is InvalidDataException && a / b == 2)
{
    Console.WriteLine("Catch");
}
catch (Exception exception) when (exception is InvalidDataException || exception is ArgumentException)
{
    Console.WriteLine("General catch");
}

Sortie: Catch.

Et comme vous pouvez le voir dans le MSILcode, le code n'est pas traduit en ifinstructions, mais en Filterset Exceptionsne peut pas être jeté à partir des zones marquées par Filter 1et Filter 2mais le filtre lançant le Exceptionéchouera à la place, également la dernière valeur de comparaison poussée dans la pile avant la endfiltercommande déterminera le succès / l'échec du filtre ( Catch 1 XOR Catch 2 s'exécutera en conséquence):

Aussi, a spécifiquement Guidla Guid.TryParseméthode.

Avec C # 7, la réponse de Michael Stum peut être améliorée tout en conservant la lisibilité d'une instruction switch:

catch (Exception ex)
{
    switch (ex)
    {
        case FormatException _:
        case OverflowException _:
            WebId = Guid.Empty;
            break;
        default:
            throw;
    }
}

Et avec C # 8 comme expression de commutateur:

catch (Exception ex)
{
    WebId = ex switch
    {
        _ when ex is FormatException || ex is OverflowException => Guid.Empty,
        _ => throw ex
    };
}

La réponse acceptée semble acceptable, sauf que CodeAnalysis / FxCop se plaindra du fait qu'il un type d'exception générale.

De plus, il semble que l'opérateur "is" puisse dégrader légèrement les performances.

CA1800: Ne jetez pas inutilement dit de "envisager de tester le résultat de l'opérateur" as "à la place", mais si vous le faites, vous écrirez plus de code que si vous interceptez chaque exception séparément.

Quoi qu'il en soit, voici ce que je ferais:

bool exThrown = false;

try
{
    // Something
}
catch (FormatException) {
    exThrown = true;
}
catch (OverflowException) {
    exThrown = true;
}

if (exThrown)
{
    // Something else
}

en C # 6 l'approche recommandée est d'utiliser des filtres d'exception, voici un exemple:

 try
 {
      throw new OverflowException();
 }
 catch(Exception e ) when ((e is DivideByZeroException) || (e is OverflowException))
 {
       // this will execute iff e is DividedByZeroEx or OverflowEx
       Console.WriteLine("E");
 }

Ceci est une variante de la réponse de Matt (je pense que c'est un peu plus propre) ... utilisez une méthode:

public void TryCatch(...)
{
    try
    {
       // something
       return;
    }
    catch (FormatException) {}
    catch (OverflowException) {}

    WebId = Guid.Empty;
}

Toute autre exception sera levée et le code WebId = Guid.Empty;ne sera pas touché. Si vous ne voulez pas que d'autres exceptions plantent votre programme, ajoutez simplement ceci APRÈS les deux autres captures:

...
catch (Exception)
{
     // something, if anything
     return; // only need this if you follow the example I gave and put it all in a method
}

La réponse de Joseph Daigle est une bonne solution, mais j'ai trouvé que la structure suivante était un peu plus ordonnée et moins sujette aux erreurs.

catch(Exception ex)
{   
    if (!(ex is SomeException || ex is OtherException)) throw;

    // Handle exception
}

Il y a quelques avantages à inverser l'expression:

• Une déclaration de retour n'est pas nécessaire
• Le code n'est pas imbriqué
• Il n'y a aucun risque d'oublier les déclarations «jeter» ou «retourner» qui, dans la solution de Joseph, sont séparées de l'expression.

Il peut même être compacté en une seule ligne (mais pas très joli)

catch(Exception ex) { if (!(ex is SomeException || ex is OtherException)) throw;

    // Handle exception
}

Edit: Le filtrage d'exceptions en C # 6.0 rendra la syntaxe un peu plus propre et offre un certain nombre d'autres avantages rapport à toute solution actuelle. (en laissant notamment la pile indemne)

Voici à quoi ressemblerait le même problème en utilisant la syntaxe C # 6.0:

catch(Exception ex) when (ex is SomeException || ex is OtherException)
{
    // Handle exception
}

@Micheal

Version légèrement révisée de votre code:

catch (Exception ex)
{
   Type exType = ex.GetType();
   if (exType == typeof(System.FormatException) || 
       exType == typeof(System.OverflowException)
   {
       WebId = Guid.Empty;
   } else {
      throw;
   }
}

Les comparaisons de chaînes sont laides et lentes.

Que diriez-vous

try
{
    WebId = Guid.Empty;
    WebId = new Guid(queryString["web"]);
}
catch (FormatException)
{
}
catch (OverflowException)
{
}

catch (Exception ex)
{
    if (!(
        ex is FormatException ||
        ex is OverflowException))
    {
        throw;
    }
    Console.WriteLine("Hello");
}

Attention et averti: Encore un autre style fonctionnel et aimable.

Ce qui est dans le lien ne répond pas directement à votre question, mais il est trivial de l'étendre pour ressembler à:

static void Main() 
{ 
    Action body = () => { ...your code... };

    body.Catch<InvalidOperationException>() 
        .Catch<BadCodeException>() 
        .Catch<AnotherException>(ex => { ...handler... })(); 
}

(Fournir essentiellement une autre Catchsurcharge vide qui se retourne)

La plus grande question à cela est pourquoi . Je ne pense pas que le coût l'emporte sur le gain ici :)

Mise à jour 2015-12-15: voir https://stackoverflow.com/a/22864936/1718702 pour C # 6. C'est un nettoyeur et désormais standard dans la langue.

Destiné aux personnes qui souhaitent une solution plus élégante pour intercepter une fois et filtrer les exceptions, j'utilise une méthode d'extension comme indiqué ci-dessous.

J'avais déjà cette extension dans ma bibliothèque, écrite à l'origine à d'autres fins, mais elle fonctionnait parfaitement pour typevérifier les exceptions. De plus, à mon humble avis, il semble plus propre qu'un tas de ||déclarations. De plus, contrairement à la réponse acceptée, je préfère la gestion des exceptions explicites, donc le ex is ...comportement était indésirable car les classes dérivées sont attribuables aux types parents).

Usage

if (ex.GetType().IsAnyOf(
    typeof(FormatException),
    typeof(ArgumentException)))
{
    // Handle
}
else
    throw;

Extension IsAnyOf.cs (Voir l'exemple complet de gestion des erreurs pour les dépendances)

namespace Common.FluentValidation
{
    public static partial class Validate
    {
        /// <summary>
        /// Validates the passed in parameter matches at least one of the passed in comparisons.
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_comparisons">Values to compare against.</param>
        /// <returns>True if a match is found.</returns>
        /// <exception cref="ArgumentNullException"></exception>
        public static bool IsAnyOf<T>(this T p_parameter, params T[] p_comparisons)
        {
            // Validate
            p_parameter
                .CannotBeNull("p_parameter");
            p_comparisons
                .CannotBeNullOrEmpty("p_comparisons");

            // Test for any match
            foreach (var item in p_comparisons)
                if (p_parameter.Equals(item))
                    return true;

            // Return no matches found
            return false;
        }
    }
}

Exemple de gestion complète des erreurs (copier-coller dans la nouvelle application console)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Common.FluentValidation;

namespace IsAnyOfExceptionHandlerSample
{
    class Program
    {
        static void Main(string[] args)
        {
            // High Level Error Handler (Log and Crash App)
            try
            {
                Foo();
            }
            catch (OutOfMemoryException ex)
            {
                Console.WriteLine("FATAL ERROR! System Crashing. " + ex.Message);
                Console.ReadKey();
            }
        }

        static void Foo()
        {
            // Init
            List<Action<string>> TestActions = new List<Action<string>>()
            {
                (key) => { throw new FormatException(); },
                (key) => { throw new ArgumentException(); },
                (key) => { throw new KeyNotFoundException();},
                (key) => { throw new OutOfMemoryException(); },
            };

            // Run
            foreach (var FooAction in TestActions)
            {
                // Mid-Level Error Handler (Appends Data for Log)
                try
                {
                    // Init
                    var SomeKeyPassedToFoo = "FooParam";

                    // Low-Level Handler (Handle/Log and Keep going)
                    try
                    {
                        FooAction(SomeKeyPassedToFoo);
                    }
                    catch (Exception ex)
                    {
                        if (ex.GetType().IsAnyOf(
                            typeof(FormatException),
                            typeof(ArgumentException)))
                        {
                            // Handle
                            Console.WriteLine("ex was {0}", ex.GetType().Name);
                            Console.ReadKey();
                        }
                        else
                        {
                            // Add some Debug info
                            ex.Data.Add("SomeKeyPassedToFoo", SomeKeyPassedToFoo.ToString());
                            throw;
                        }
                    }
                }
                catch (KeyNotFoundException ex)
                {
                    // Handle differently
                    Console.WriteLine(ex.Message);

                    int Count = 0;
                    if (!Validate.IsAnyNull(ex, ex.Data, ex.Data.Keys))
                        foreach (var Key in ex.Data.Keys)
                            Console.WriteLine(
                                "[{0}][\"{1}\" = {2}]",
                                Count, Key, ex.Data[Key]);

                    Console.ReadKey();
                }
            }
        }
    }
}

namespace Common.FluentValidation
{
    public static partial class Validate
    {
        /// <summary>
        /// Validates the passed in parameter matches at least one of the passed in comparisons.
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_comparisons">Values to compare against.</param>
        /// <returns>True if a match is found.</returns>
        /// <exception cref="ArgumentNullException"></exception>
        public static bool IsAnyOf<T>(this T p_parameter, params T[] p_comparisons)
        {
            // Validate
            p_parameter
                .CannotBeNull("p_parameter");
            p_comparisons
                .CannotBeNullOrEmpty("p_comparisons");

            // Test for any match
            foreach (var item in p_comparisons)
                if (p_parameter.Equals(item))
                    return true;

            // Return no matches found
            return false;
        }

        /// <summary>
        /// Validates if any passed in parameter is equal to null.
        /// </summary>
        /// <param name="p_parameters">Parameters to test for Null.</param>
        /// <returns>True if one or more parameters are null.</returns>
        public static bool IsAnyNull(params object[] p_parameters)
        {
            p_parameters
                .CannotBeNullOrEmpty("p_parameters");

            foreach (var item in p_parameters)
                if (item == null)
                    return true;

            return false;
        }
    }
}

namespace Common.FluentValidation
{
    public static partial class Validate
    {
        /// <summary>
        /// Validates the passed in parameter is not null, throwing a detailed exception message if the test fails.
        /// </summary>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_name">Name of tested parameter to assist with debugging.</param>
        /// <exception cref="ArgumentNullException"></exception>
        public static void CannotBeNull(this object p_parameter, string p_name)
        {
            if (p_parameter == null)
                throw
                    new
                        ArgumentNullException(
                        string.Format("Parameter \"{0}\" cannot be null.",
                        p_name), default(Exception));
        }
    }
}

namespace Common.FluentValidation
{
    public static partial class Validate
    {
        /// <summary>
        /// Validates the passed in parameter is not null or an empty collection, throwing a detailed exception message if the test fails.
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_name">Name of tested parameter to assist with debugging.</param>
        /// <exception cref="ArgumentNullException"></exception>
        /// <exception cref="ArgumentOutOfRangeException"></exception>
        public static void CannotBeNullOrEmpty<T>(this ICollection<T> p_parameter, string p_name)
        {
            if (p_parameter == null)
                throw new ArgumentNullException("Collection cannot be null.\r\nParameter_Name: " + p_name, default(Exception));

            if (p_parameter.Count <= 0)
                throw new ArgumentOutOfRangeException("Collection cannot be empty.\r\nParameter_Name: " + p_name, default(Exception));
        }

        /// <summary>
        /// Validates the passed in parameter is not null or empty, throwing a detailed exception message if the test fails.
        /// </summary>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_name">Name of tested parameter to assist with debugging.</param>
        /// <exception cref="ArgumentException"></exception>
        public static void CannotBeNullOrEmpty(this string p_parameter, string p_name)
        {
            if (string.IsNullOrEmpty(p_parameter))
                throw new ArgumentException("String cannot be null or empty.\r\nParameter_Name: " + p_name, default(Exception));
        }
    }
}

Deux exemples de tests unitaires NUnit

Le comportement de correspondance pour les Exceptiontypes est exact (c'est-à-dire qu'un enfant N'EST PAS une correspondance pour aucun de ses types parents).

using System;
using System.Collections.Generic;
using Common.FluentValidation;
using NUnit.Framework;

namespace UnitTests.Common.Fluent_Validations
{
    [TestFixture]
    public class IsAnyOf_Tests
    {
        [Test, ExpectedException(typeof(ArgumentNullException))]
        public void IsAnyOf_ArgumentNullException_ShouldNotMatch_ArgumentException_Test()
        {
            Action TestMethod = () => { throw new ArgumentNullException(); };

            try
            {
                TestMethod();
            }
            catch (Exception ex)
            {
                if (ex.GetType().IsAnyOf(
                    typeof(ArgumentException), /*Note: ArgumentNullException derrived from ArgumentException*/
                    typeof(FormatException),
                    typeof(KeyNotFoundException)))
                {
                    // Handle expected Exceptions
                    return;
                }

                //else throw original
                throw;
            }
        }

        [Test, ExpectedException(typeof(OutOfMemoryException))]
        public void IsAnyOf_OutOfMemoryException_ShouldMatch_OutOfMemoryException_Test()
        {
            Action TestMethod = () => { throw new OutOfMemoryException(); };

            try
            {
                TestMethod();
            }
            catch (Exception ex)
            {
                if (ex.GetType().IsAnyOf(
                    typeof(OutOfMemoryException),
                    typeof(StackOverflowException)))
                    throw;

                /*else... Handle other exception types, typically by logging to file*/
            }
        }
    }
}

Comme j'avais l'impression que ces réponses touchaient la surface, j'ai essayé de creuser un peu plus profondément.

Donc, ce que nous voudrions vraiment faire, c'est quelque chose qui ne compile pas, disons:

// Won't compile... damn
public static void Main()
{
    try
    {
        throw new ArgumentOutOfRangeException();
    }
    catch (ArgumentOutOfRangeException)
    catch (IndexOutOfRangeException) 
    {
        // ... handle
    }

La raison pour laquelle nous voulons cela est parce que nous ne voulons pas que le gestionnaire d'exceptions intercepte les éléments dont nous avons besoin plus tard dans le processus. Bien sûr, nous pouvons attraper une exception et vérifier avec un «si» quoi faire, mais soyons honnêtes, nous ne voulons pas vraiment cela. (FxCop, problèmes de débogage, laideur)

Alors pourquoi ce code ne compile-t-il pas - et comment pouvons-nous le pirater de telle manière qu'il le fera?

Si nous regardons le code, ce que nous aimerions vraiment faire, c'est transférer l'appel. Cependant, selon MS Partition II, les blocs de gestionnaire d'exceptions IL ne fonctionneront pas comme cela, ce qui dans ce cas est logique car cela impliquerait que l'objet «exception» peut avoir différents types.

Ou pour l'écrire dans le code, nous demandons au compilateur de faire quelque chose comme ça (enfin ce n'est pas tout à fait correct, mais c'est la chose la plus proche possible je suppose):

// Won't compile... damn
try
{
    throw new ArgumentOutOfRangeException();
}
catch (ArgumentOutOfRangeException e) {
    goto theOtherHandler;
}
catch (IndexOutOfRangeException e) {
theOtherHandler:
    Console.WriteLine("Handle!");
}

La raison pour laquelle cela ne se compile pas est tout à fait évidente: quel type et quelle valeur aurait l'objet '$ exception' (qui sont ici stockés dans les variables 'e')? La façon dont nous voulons que le compilateur gère cela est de noter que le type de base commun des deux exceptions est «Exception», utilisez-le pour qu'une variable contienne les deux exceptions, puis ne gérez que les deux exceptions qui sont interceptées. La façon dont cela est implémenté dans IL est comme un «filtre», qui est disponible dans VB.Net.

Pour le faire fonctionner en C #, nous avons besoin d'une variable temporaire avec le type de base 'Exception' correct. Pour contrôler le flux du code, nous pouvons ajouter quelques branches. Voici:

    Exception ex;
    try
    {
        throw new ArgumentException(); // for demo purposes; won't be caught.
        goto noCatch;
    }
    catch (ArgumentOutOfRangeException e) {
        ex = e;
    }
    catch (IndexOutOfRangeException e) {
        ex = e;
    }

    Console.WriteLine("Handle the exception 'ex' here :-)");
    // throw ex ?

noCatch:
    Console.WriteLine("We're done with the exception handling.");

Les inconvénients évidents pour cela sont que nous ne pouvons pas relancer correctement, et - soyons honnêtes - c'est tout à fait la solution laide. La laideur peut être corrigée un peu en effectuant l'élimination des branches, ce qui rend la solution légèrement meilleure:

Exception ex = null;
try
{
    throw new ArgumentException();
}
catch (ArgumentOutOfRangeException e)
{
    ex = e;
}
catch (IndexOutOfRangeException e)
{
    ex = e;
}
if (ex != null)
{
    Console.WriteLine("Handle the exception here :-)");
}

Cela ne laisse que le «re-throw». Pour que cela fonctionne, nous devons être en mesure d'effectuer la gestion à l'intérieur du bloc «catch» - et la seule façon de faire fonctionner cela est par un objet «Exception» de capture.

À ce stade, nous pouvons ajouter une fonction distincte qui gère les différents types d'exceptions à l'aide de la résolution de surcharge ou pour gérer l'exception. Les deux ont des inconvénients. Pour commencer, voici la façon de le faire avec une fonction d'assistance:

private static bool Handle(Exception e)
{
    Console.WriteLine("Handle the exception here :-)");
    return true; // false will re-throw;
}

public static void Main()
{
    try
    {
        throw new OutOfMemoryException();
    }
    catch (ArgumentException e)
    {
        if (!Handle(e)) { throw; }
    }
    catch (IndexOutOfRangeException e)
    {
        if (!Handle(e)) { throw; }
    }

    Console.WriteLine("We're done with the exception handling.");

Et l'autre solution consiste à intercepter l'objet Exception et à le gérer en conséquence. La traduction la plus littérale pour cela, basée sur le contexte ci-dessus est la suivante:

try
{
    throw new ArgumentException();
}
catch (Exception e)
{
    Exception ex = (Exception)(e as ArgumentException) ?? (e as IndexOutOfRangeException);
    if (ex != null)
    {
        Console.WriteLine("Handle the exception here :-)");
        // throw ?
    }
    else 
    {
        throw;
    }
}

Donc pour conclure:

• Si nous ne voulons pas relancer, nous pourrions envisager d'attraper les bonnes exceptions et de les stocker dans un fichier temporaire.
• Si le gestionnaire est simple et que nous voulons réutiliser le code, la meilleure solution est probablement d'introduire une fonction d'aide.
• Si nous voulons relancer, nous n'avons pas d'autre choix que de mettre le code dans un gestionnaire de capture «Exception», ce qui cassera FxCop et les exceptions non capturées de votre débogueur.

C'est un problème classique auquel tous les développeurs C # sont confrontés.

Permettez-moi de diviser votre question en 2 questions. La première,

Puis-je intercepter plusieurs exceptions à la fois?

Bref, non.

Ce qui nous amène à la question suivante,

Comment éviter d'écrire du code en double étant donné que je ne peux pas intercepter plusieurs types d'exceptions dans le même bloc catch ()?

Compte tenu de votre échantillon spécifique, où la valeur de secours est bon marché à construire, j'aime suivre ces étapes:

1. Initialisez WebId à la valeur de secours.
2. Construisez un nouveau Guid dans une variable temporaire.
3. Définissez WebId sur la variable temporaire entièrement construite. Faites-en la déclaration finale du bloc try {}.

Le code ressemble donc à:

try
{
    WebId = Guid.Empty;
    Guid newGuid = new Guid(queryString["web"]);
    // More initialization code goes here like 
    // newGuid.x = y;
    WebId = newGuid;
}
catch (FormatException) {}
catch (OverflowException) {}

Si une exception est levée, WebId n'est jamais défini sur la valeur semi-construite et reste Guid.Empty.

Si la construction de la valeur de secours est coûteuse et que la réinitialisation d'une valeur est beaucoup moins chère, je déplacerais le code de réinitialisation dans sa propre fonction:

try
{
    WebId = new Guid(queryString["web"]);
    // More initialization code goes here.
}
catch (FormatException) {
    Reset(WebId);
}
catch (OverflowException) {
    Reset(WebId);
}

Vous répétez donc beaucoup de code dans chaque commutateur d'exception? On dirait que l'extraction d'une méthode serait une idée divine, n'est-ce pas?

Donc, votre code se résume à ceci:

MyClass instance;
try { instance = ... }
catch(Exception1 e) { Reset(instance); }
catch(Exception2 e) { Reset(instance); }
catch(Exception) { throw; }

void Reset(MyClass instance) { /* reset the state of the instance */ }

Je me demande pourquoi personne n'a remarqué cette duplication de code.

De C # 6, vous avez en outre les filtres d'exception comme déjà mentionné par d'autres. Vous pouvez donc modifier le code ci-dessus en ceci:

try { ... }
catch(Exception e) when(e is Exception1 || e is Exception2)
{ 
    Reset(instance); 
}

Je voulais ajouter ma réponse courte à ce fil déjà long. Quelque chose qui n'a pas été mentionné est l'ordre de priorité des instructions catch, plus précisément vous devez être conscient de la portée de chaque type d'exception que vous essayez d'attraper.

Par exemple , si vous utilisez un « fourre-tout » exception comme exception il précédera toutes les autres déclarations de captures et vous aurez évidemment obtenir des erreurs compilateur si vous inversez l'ordre que vous pouvez enchaîner vos déclarations de captures (peu d'un anti-modèle que je pense ), vous pouvez mettre le type d' exception fourre-tout en bas et ce sera capturer toutes les exceptions qui ne répondaient pas plus haut dans votre bloc try..catch:

            try
            {
                // do some work here
            }
            catch (WebException ex)
            {
                // catch a web excpetion
            }
            catch (ArgumentException ex)
            {
                // do some stuff
            }
            catch (Exception ex)
            {
                // you should really surface your errors but this is for example only
                throw new Exception("An error occurred: " + ex.Message);
            }

Je recommande fortement aux gens de lire ce document MSDN:

Hiérarchie des exceptions

Peut-être essayez-vous de garder votre code simple, par exemple en mettant le code commun dans une méthode, comme vous le feriez dans toute autre partie du code qui ne se trouve pas dans une clause catch?

Par exemple:

try
{
    // ...
}
catch (FormatException)
{
    DoSomething();
}
catch (OverflowException)
{
    DoSomething();
}

// ...

private void DoSomething()
{
    // ...
}

Juste comment je le ferais, en essayant de trouver le modèle simple et magnifique

Notez que j'ai trouvé une façon de le faire, mais cela ressemble plus à du matériel pour The Daily WTF :

catch (Exception ex)
{
    switch (ex.GetType().Name)
    {
        case "System.FormatException":
        case "System.OverflowException":
            WebId = Guid.Empty;
            break;
        default:
            throw;
    }
}

Il convient de mentionner ici. Vous pouvez répondre aux multiples combinaisons (erreur d'exception et message d'exception).

J'ai rencontré un scénario de cas d'utilisation en essayant de caster un objet de contrôle dans une grille de données, avec un contenu comme TextBox, TextBlock ou CheckBox. Dans ce cas, l'exception renvoyée était la même, mais le message variait.

try
{
 //do something
}
catch (Exception ex) when (ex.Message.Equals("the_error_message1_here"))
{
//do whatever you like
} 
catch (Exception ex) when (ex.Message.Equals("the_error_message2_here"))
{
//do whatever you like
} 

Je veux suggérer la réponse la plus courte (un style plus fonctionnel ):

        Catch<FormatException, OverflowException>(() =>
            {
                WebId = new Guid(queryString["web"]);
            },
            exception =>
            {
                WebId = Guid.Empty;
            });

Pour cela, vous devez créer plusieurs surcharges de méthode "Catch", similaires à System.Action:

    [DebuggerNonUserCode]
    public static void Catch<TException1, TException2>(Action tryBlock,
        Action<Exception> catchBlock)
    {
        CatchMany(tryBlock, catchBlock, typeof(TException1), typeof(TException2));
    }

    [DebuggerNonUserCode]
    public static void Catch<TException1, TException2, TException3>(Action tryBlock,
        Action<Exception> catchBlock)
    {
        CatchMany(tryBlock, catchBlock, typeof(TException1), typeof(TException2), typeof(TException3));
    }

et ainsi de suite autant que vous le souhaitez. Mais vous devez le faire une fois et vous pouvez l'utiliser dans tous vos projets (ou, si vous avez créé un paquet nuget, nous pourrions également l'utiliser).

Et la mise en œuvre de CatchMany:

    [DebuggerNonUserCode]
    public static void CatchMany(Action tryBlock, Action<Exception> catchBlock,
        params Type[] exceptionTypes)
    {
        try
        {
            tryBlock();
        }
        catch (Exception exception)
        {
            if (exceptionTypes.Contains(exception.GetType())) catchBlock(exception);
            else throw;
        }
    }

ps Je n'ai pas mis de vérification nulle pour la simplicité du code, pensez à ajouter des validations de paramètres.

ps2 Si vous souhaitez renvoyer une valeur de catch, il est nécessaire de faire les mêmes méthodes Catch, mais avec des retours et Func au lieu d'Action dans les paramètres.

Il suffit d'appeler l'essai et d'attraper deux fois.

try
{
    WebId = new Guid(queryString["web"]);
}
catch (FormatException)
{
    WebId = Guid.Empty;
}
try
{
    WebId = new Guid(queryString["web"]);
}
catch (OverflowException)
{
    WebId = Guid.Empty;
}

C'est aussi simple que ça !!

Dans c # 6.0, les filtres d'exception sont des améliorations pour la gestion des exceptions

try
{
    DoSomeHttpRequest();
}
catch (System.Web.HttpException e)
{
    switch (e.GetHttpCode())
    {
        case 400:
            WriteLine("Bad Request");
        case 500:
            WriteLine("Internal Server Error");
        default:
            WriteLine("Generic Error");
    }
}