Cattura più eccezioni contemporaneamente?

Si scoraggia semplicemente per catturare System.Exception . Invece, dovrebbero essere rilevate solo le eccezioni "conosciute".

Ora, questo a volte porta a un codice ripetitivo non necessario, ad esempio:

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

Mi chiedo: c'è un modo per catturare entrambe le eccezioni e chiamare la WebId = Guid.Emptychiamata solo una volta?

L'esempio dato è piuttosto semplice, in quanto è solo un GUID. Ma immagina il codice in cui modifichi più volte un oggetto e se una delle manipolazioni fallisce in modo previsto, vuoi "resettare" il file object. Tuttavia, se c'è un'eccezione inaspettata, voglio ancora lanciarlo più in alto.

Cattura System.Exceptione attiva i tipi

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

    throw;
}

EDIT: concordo con gli altri che stanno dicendo che, a partire da C # 6.0, i filtri delle eccezioni sono ora un modo perfetto per andare:catch (Exception ex) when (ex is ... || ex is ... )

Tranne il fatto che odio ancora il layout a una riga lunga e che definirei il codice come segue. Penso che sia tanto funzionale quanto estetico, poiché credo che migliora la comprensione. Alcuni potrebbero non essere d'accordo:

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

ORIGINALE:

So di essere un po 'in ritardo alla festa qui, ma fumo santo ...

Passando direttamente all'inseguimento, questo tipo di duplica una risposta precedente, ma se vuoi davvero eseguire un'azione comune per diversi tipi di eccezione e mantenere tutto pulito e ordinato nell'ambito di un metodo, perché non usare semplicemente un lambda / chiusura / funzione in linea per fare qualcosa di simile al seguente? Voglio dire, è molto probabile che finirai per capire che vuoi solo rendere quella chiusura un metodo separato che puoi utilizzare ovunque. Ma sarà super facile farlo senza cambiare strutturalmente il resto del codice. Giusto?

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 ); }
}

Non posso fare a meno di chiedermi ( avvertimento: un po 'di ironia / sarcasmo davanti) perché mai fare tutto questo sforzo per sostituire semplicemente quanto segue:

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

... con qualche variazione folle di questo odore di codice successivo, intendo esempio, solo per far finta che stai salvando alcune sequenze di tasti.

// 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;
}

Perché certamente non è automaticamente più leggibile.

Concesso, ho lasciato le tre identiche istanze di /* write to a log, whatever... */ return; del primo esempio.

Ma è una specie del mio punto. Avete sentito parlare di funzioni / metodi, giusto? Sul serio. Scrivi un comuneErrorHandler funzione e, come, chiamala da ciascun blocco catch.

Se me lo chiedi, il secondo esempio (con il ifeis parole chiave ) è significativamente meno leggibile e contemporaneamente significativamente più soggetto a errori durante la fase di manutenzione del tuo progetto.

La fase di manutenzione, per chiunque sia relativamente nuovo nella programmazione, comprenderà il 98,7% o più della durata complessiva del progetto e il povero schmuck che fa la manutenzione sarà quasi sicuramente qualcuno diverso da te. E c'è una buona probabilità che trascorrano il 50% del loro tempo sul lavoro maledicendo il tuo nome.

E ovviamente FxCop ti abbaia e quindi devi anche aggiungere un attributo al tuo codice che ha esattamente zip a che fare con il programma in esecuzione, ed è lì solo per dire a FxCop di ignorare un problema che nel 99,9% dei casi è totalmente corretto nella segnalazione. E, scusa, potrei sbagliarmi, ma l'attributo "ignora" non viene effettivamente compilato nella tua app?

Metterebbe l'intero if test su una riga lo renderebbe più leggibile? Io non la penso così. Voglio dire, molto tempo fa un altro programmatore sosteneva con veemenza che mettere più codice su una riga lo avrebbe fatto "correre più veloce". Ma ovviamente era completamente pazzo. Cercare di spiegargli (con una faccia seria - il che era una sfida) come l'interprete o il compilatore avrebbero spezzato quella lunga riga in discrete istruzioni una per riga - sostanzialmente identiche al risultato se fosse andato avanti e ha appena reso leggibile il codice invece di provare a fare il furbo del compilatore - non ha avuto alcun effetto su di lui. Ma sto divagando.

Quanto meno leggibile si ottiene quando si aggiungono altri tre tipi di eccezione, tra un mese o due? (Risposta: diventa molto meno leggibile).

Uno dei punti principali, in realtà, è che la maggior parte del punto di formattazione del codice sorgente testuale che tutti noi guardiamo ogni giorno è quello di rendere davvero, davvero ovvio agli altri esseri umani ciò che sta realmente accadendo quando il codice viene eseguito. Perché il compilatore trasforma il codice sorgente in qualcosa di completamente diverso e non potrebbe importare di meno del tuo stile di formattazione del codice. Quindi anche tutto on-one-one-line fa schifo.

Sto solo dicendo ...

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

Come altri hanno sottolineato, puoi avere una ifdichiarazione all'interno del blocco catch per determinare cosa sta succedendo. C # 6 supporta i filtri di eccezione, quindi funzionerà quanto segue:

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

Il MyFiltermetodo potrebbe quindi assomigliare a questo:

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

In alternativa, tutto ciò può essere fatto in linea (il lato destro dell'istruzione when deve essere solo un'espressione booleana).

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

Ciò è diverso dall'uso di ifun'istruzione all'interno del catchblocco, l'utilizzo dei filtri delle eccezioni no lo stack.

È possibile scaricare Visual Studio 2015 per verificarlo.

Se si desidera continuare a utilizzare Visual Studio 2013, è possibile installare il seguente pacchetto nuget:

Pacchetti di installazione Microsoft.Net.Compilers

Al momento della stesura, questo includerà il supporto per C # 6.

Facendo riferimento a questo pacchetto, il progetto verrà creato utilizzando la versione specifica dei compilatori C # e Visual Basic contenuti nel pacchetto, al contrario di qualsiasi versione installata sul sistema.

Purtroppo non in C #, poiché per farlo è necessario un filtro di eccezioni e C # non espone quella funzionalità di MSIL. VB.NET ha questa capacità, ad es

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

Quello che potresti fare è usare una funzione anonima per incapsulare il tuo codice di errore e quindi chiamarlo in quei blocchi catch specifici:

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

Per completezza, da .NET 4.0 il codice può essere riscritto come:

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

TryParse non genera mai eccezioni e restituisce false se il formato è errato, impostando WebId su Guid.Empty.

Da C # 7 puoi evitare di introdurre una variabile su una riga separata:

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

Puoi anche creare metodi per analizzare le tuple di ritorno, che non sono ancora disponibili in .NET Framework dalla versione 4.6:

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

E usali in questo modo:

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

Il prossimo aggiornamento inutile a questa risposta inutile arriva quando la decostruzione dei parametri fuori è implementata in C # 12. :)

I filtri di eccezione sono ora disponibili in c # 6+. Tu puoi fare

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

In C # 7.0+, puoi anche combinare questo con la corrispondenza dei motivi

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..? 
}

Se riesci ad aggiornare la tua applicazione a C # 6 sei fortunato. La nuova versione di C # ha implementato i filtri di eccezione. Quindi puoi scrivere questo:

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

Alcune persone pensano che questo codice sia lo stesso di

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

Ma non lo è. In realtà questa è l'unica nuova funzionalità in C # 6 che non è possibile emulare nelle versioni precedenti. In primo luogo, un rilancio significa più spese generali che saltare il pescato. In secondo luogo, non è semanticamente equivalente. La nuova funzionalità mantiene intatto lo stack durante il debug del codice. Senza questa funzione il dump dell'arresto anomalo è meno utile o addirittura inutile.

Vedi una discussione al riguardo su CodePlex . E un esempio che mostra la differenza .

Se non si desidera utilizzare un ifcomunicato all'interno delle catchambiti, in C# 6.0è possibile utilizzare Exception Filtersla sintassi che è stato già sostenuto dal CLR nelle versioni anteprime, ma esisteva solo in VB.NET/ MSIL:

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

Questo codice prenderà il Exceptionsolo quando è un InvalidDataExceptionoArgumentNullException .

In realtà, puoi inserire praticamente qualsiasi condizione all'interno di quella whenclausola:

static int a = 8;

...

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

Si noti che a differenza di ifun'istruzione all'interno catchdell'ambito, Exception Filtersnon può essere lanciata Exceptions, e quando lo fanno, o quando la condizione non lo è true, catchverrà invece valutata la condizione successiva :

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");
}

Uscita: cattura generale.

Quando ce n'è più di uno true Exception Filter, il primo verrà accettato:

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");
}

Uscita: cattura.

E come puoi vedere nel MSILcodice non viene tradotto in ifistruzioni, ma in Filters, e Exceptionsnon può essere lanciato dall'interno delle aree contrassegnate con Filter 1e Filter 2ma il filtro che lancia Exceptionil endfiltercomando fallirà invece, anche l'ultimo valore di confronto inserito nello stack prima del comando determinerà l'esito positivo / negativo del filtro ( Catch 1 XOR Catch 2 verrà eseguito di conseguenza):

Inoltre, Guidha specificamente il Guid.TryParsemetodo.

Con C # 7 la risposta di Michael Stum può essere migliorata mantenendo la leggibilità di un'istruzione switch:

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

E con C # 8 come espressione switch:

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

La risposta accettata sembra accettabile, tranne per il fatto che CodeAnalysis / FxCop si lamenterà del fatto che sta rilevando un tipo di eccezione generale.

Inoltre, sembra che l'operatore "is" possa degradare leggermente le prestazioni.

CA1800: non eseguire il cast inutilmente dice di "considerare invece di testare il risultato dell'operatore" as ", ma se lo fai, scriverai più codice che se prendi ogni eccezione separatamente.

Comunque, ecco cosa farei:

bool exThrown = false;

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

if (exThrown)
{
    // Something else
}

in C # 6 l'approccio raccomandato è di usare i filtri di eccezione, ecco un esempio:

 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");
 }

Questa è una variante della risposta di Matt (penso che sia un po 'più pulita) ... usa un metodo:

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

    WebId = Guid.Empty;
}

Eventuali altre eccezioni verranno generate e il codice WebId = Guid.Empty;non verrà colpito. Se non desideri che altre eccezioni causino l'arresto anomalo del programma, aggiungi questo DOPO le altre due catture:

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

La risposta di Joseph Daigle è una buona soluzione, ma ho trovato la seguente struttura un po 'più ordinata e meno soggetta a errori.

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

    // Handle exception
}

Ci sono alcuni vantaggi dell'inversione dell'espressione:

• Non è necessaria una dichiarazione di reso
• Il codice non è nidificato
• Non vi è alcun rischio di dimenticare le dichiarazioni di "lancio" o "ritorno" che nella soluzione di Joseph sono separate dall'espressione.

Può anche essere compattato su una sola riga (anche se non molto carina)

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

    // Handle exception
}

Modifica: il filtro delle eccezioni in C # 6.0 renderà la sintassi un po 'più pulita e offre una serie di altri vantaggi rispetto a qualsiasi soluzione attuale. (in particolare lasciando incolume lo stack)

Ecco come apparirebbe lo stesso problema usando la sintassi di C # 6.0:

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

@Micheal

Versione leggermente rivista del codice:

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

I confronti delle stringhe sono brutti e lenti.

Che ne dite di

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");
}

Attenzione e avvertimento: ancora un altro tipo, stile funzionale.

Ciò che è nel link non risponde direttamente alla tua domanda, ma è banale estenderla per assomigliare a:

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

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

(Fondamentalmente fornire un altro Catchsovraccarico vuoto che ritorna se stesso)

La domanda più grande a questo è perché . Non credo che il costo superi il guadagno qui :)

Aggiornamento 2015-12-15: consultare https://stackoverflow.com/a/22864936/1718702 per C # 6. È più pulito e ora standard nella lingua.

Pensato per le persone che desiderano una soluzione più elegante da catturare una volta e filtrare le eccezioni, utilizzo un metodo di estensione come dimostrato di seguito.

Avevo già questa estensione nella mia libreria, originariamente scritta per altri scopi, ma ha funzionato perfettamente per typeverificare le eccezioni. Inoltre, imho, sembra più pulito di un mucchio di ||affermazioni. Inoltre, a differenza della risposta accettata, preferisco la gestione esplicita delle eccezioni, così ex is ...come il comportamento indesiderabile in quanto le classi derrived sono assegnabili ai tipi parent).

uso

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

Estensione IsAnyOf.cs (vedere l'esempio completo di gestione degli errori per le dipendenze)

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;
        }
    }
}

Esempio di gestione completa degli errori (Copia-Incolla nella nuova app 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));
        }
    }
}

Due test di unità NUnit di esempio

Il comportamento della corrispondenza per i Exceptiontipi è esatto (es. Un bambino NON È una corrispondenza per nessuno dei suoi tipi principali).

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*/
            }
        }
    }
}

Dato che mi sembrava che queste risposte avessero appena toccato la superficie, ho cercato di scavare un po 'più a fondo.

Quindi quello che vorremmo davvero fare è qualcosa che non viene compilato, ad esempio:

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

Il motivo per cui lo vogliamo è perché non vogliamo che il gestore delle eccezioni catturi le cose di cui abbiamo bisogno in seguito nel processo. Certo, possiamo prendere un'eccezione e verificare con un 'se' cosa fare, ma siamo sinceri, non lo vogliamo davvero. (FxCop, problemi di debugger, bruttezza)

Quindi perché questo codice non viene compilato - e come possiamo hackerarlo in modo tale da farlo?

Se osserviamo il codice, ciò che vorremmo davvero fare è inoltrare la chiamata. Tuttavia, secondo MS Partition II, i blocchi del gestore di eccezioni IL non funzioneranno in questo modo, il che in questo caso ha senso perché ciò implicherebbe che l'oggetto "eccezione" può avere tipi diversi.

O per scriverlo in codice, chiediamo al compilatore di fare qualcosa del genere (beh non è del tutto corretto, ma è la cosa più vicina possibile immagino):

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

Il motivo per cui questo non verrà compilato è abbastanza ovvio: che tipo e valore avrebbe l'oggetto '$ exception' (che qui sono memorizzati nelle variabili 'e')? Il modo in cui vogliamo che il compilatore gestisca ciò è notare che il tipo di base comune di entrambe le eccezioni è 'Eccezione', usalo per una variabile che contenga entrambe le eccezioni, quindi gestisci solo le due eccezioni che vengono rilevate. Il modo in cui questo è implementato in IL è come 'filtro', che è disponibile in VB.Net.

Per farlo funzionare in C #, abbiamo bisogno di una variabile temporanea con il tipo di base "Eccezione" corretto. Per controllare il flusso del codice, possiamo aggiungere alcuni rami. Ecco qui:

    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.");

Gli ovvi svantaggi di ciò sono che non possiamo ri-lanciare correttamente e, beh, siamo onesti, che è una brutta soluzione. La bruttezza può essere risolta un po 'eseguendo l'eliminazione del ramo, il che rende la soluzione leggermente migliore:

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 :-)");
}

Questo lascia solo il "rilancio". Perché ciò funzioni, dobbiamo essere in grado di eseguire la gestione all'interno del blocco "catch" - e l'unico modo per farlo funzionare è catturare un oggetto "Exception".

A questo punto, possiamo aggiungere una funzione separata che gestisce i diversi tipi di eccezioni utilizzando la risoluzione di sovraccarico o per gestire l'eccezione. Entrambi hanno degli svantaggi. Per iniziare, ecco il modo di farlo con una funzione di supporto:

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.");

E l'altra soluzione è catturare l'oggetto Exception e gestirlo di conseguenza. La traduzione più letterale per questo, basata sul contesto sopra è questa:

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;
    }
}

Quindi per concludere:

• Se non vogliamo rilanciare, potremmo prendere in considerazione la possibilità di catturare le giuste eccezioni e conservarle in modo temporaneo.
• Se il gestore è semplice e vogliamo riutilizzare il codice, la soluzione migliore è probabilmente quella di introdurre una funzione di supporto.
• Se vogliamo rilanciare, non abbiamo altra scelta che mettere il codice in un gestore catch 'Exception', che romperà FxCop e le eccezioni non rilevate del tuo debugger.

Questo è un problema classico che ogni sviluppatore di C # deve affrontare alla fine.

Vorrei dividere la tua domanda in 2 domande. Il primo,

Posso rilevare più eccezioni contemporaneamente?

In breve, no.

Il che porta alla domanda successiva,

Come evitare di scrivere codice duplicato dato che non riesco a catturare più tipi di eccezione nello stesso blocco catch ()?

Dato il tuo esempio specifico, in cui il valore di fallback è economico da costruire, mi piace seguire questi passaggi:

1. Inizializza WebId sul valore di fallback.
2. Costruisci un nuovo Guid in una variabile temporanea.
3. Impostare WebId sulla variabile temporanea completamente costruita. Imposta come dichiarazione finale del blocco try {}.

Quindi il codice è simile al seguente:

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) {}

Se viene generata un'eccezione, WebId non viene mai impostato sul valore semi-costruito e rimane Guid.Empty.

Se la costruzione del valore di fallback è costosa e il ripristino di un valore è molto più economico, spostare il codice di ripristino nella sua funzione:

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

Quindi stai ripetendo molto codice all'interno di ogni switch di eccezioni? Sembra che estrarre un metodo sarebbe un'idea divina, vero?

Quindi il tuo codice si riduce a questo:

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 */ }

Mi chiedo perché nessuno abbia notato quella duplicazione del codice.

Da C # 6 hai inoltre i filtri delle eccezioni come già menzionato da altri. Quindi puoi modificare il codice sopra a questo:

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

Volevo aggiungere la mia breve risposta a questo thread già lungo. Qualcosa che non è stato menzionato è l'ordine di precedenza delle dichiarazioni catch, in particolare è necessario essere consapevoli dell'ambito di ciascun tipo di eccezione che si sta tentando di rilevare.

Ad esempio, se usi un'eccezione "catch-all" come Eccezione , precederà tutte le altre dichiarazioni di cattura e otterrai ovviamente errori del compilatore, tuttavia se inverti l'ordine puoi incatenare le tue dichiarazioni di cattura (un po 'di un anti-pattern, penso ) puoi mettere il tipo di eccezione catch-all in fondo e questo catturerà tutte le eccezioni che non soddisfano più in alto nel tuo blocco 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);
            }

Consiglio vivamente alle persone di leggere questo documento MSDN:

Gerarchia di eccezioni

Forse provi a mantenere il tuo codice semplice come mettere il codice comune in un metodo, come faresti in qualsiasi altra parte del codice che non è all'interno di una clausola catch?

Per esempio:

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

// ...

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

Proprio come lo farei, cercare di trovare il modello semplice è bello

Nota che ho trovato un modo per farlo, ma sembra più materiale per The Daily WTF :

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

Vale la pena menzionarlo qui. È possibile rispondere a più combinazioni (errore di eccezione e messaggio di eccezione).

Mi sono imbattuto in uno scenario di utilizzo quando ho provato a lanciare un oggetto di controllo in un datagrid, con contenuto come TextBox, TextBlock o CheckBox. In questo caso, l'eccezione restituita era la stessa, ma il messaggio variava.

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
} 

Voglio suggerire la risposta più breve (un altro stile funzionale ):

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

Per questo è necessario creare diversi overload del metodo "Catch", simile a 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));
    }

e così via quante ne desideri. Ma devi farlo una volta e puoi usarlo in tutti i tuoi progetti (o, se hai creato un pacchetto nuget, potremmo usarlo anche noi).

E l'implementazione di 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 Non ho messo i controlli null per la semplicità del codice, considera di aggiungere convalide dei parametri.

ps2 Se si desidera restituire un valore dal catch, è necessario eseguire gli stessi metodi Catch, ma con return e Func anziché Action nei parametri.

Basta chiamare il tentativo e prendere due volte.

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

È così semplice !!

In c # 6.0, Filtri eccezioni sono miglioramenti per la gestione delle eccezioni

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");
    }
}