Złapać wiele wyjątków jednocześnie?

Odradza się po prostu łapanie System.Exception. Zamiast tego należy wychwytywać tylko „znane” wyjątki.

To czasami prowadzi do niepotrzebnego powtarzającego się kodu, na przykład:

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

Zastanawiam się: czy istnieje sposób, aby złapać oba wyjątki i zadzwonić tylko WebId = Guid.Emptyraz?

Podany przykład jest raczej prosty, ponieważ jest to tylko GUID. Ale wyobraź sobie kod, w którym wielokrotnie modyfikujesz obiekt, a jeśli jedna z manipulacji zakończy się w oczekiwany sposób, chcesz „zresetować” object. Jeśli jednak wystąpi nieoczekiwany wyjątek, nadal chcę go podnieść.

Złap System.Exceptioni włącz typy

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

    throw;
}

EDYCJA: Zgadzam się z innymi, którzy twierdzą, że od wersji C # 6.0 filtry wyjątków są teraz całkiem dobrym sposobem:catch (Exception ex) when (ex is ... || ex is ... )

Tyle że nadal nienawidzę układu z jedną linią i osobiście ułożyłem kod w następujący sposób. Myślę, że jest to tak funkcjonalne, jak estetyczne, ponieważ uważam, że poprawia zrozumienie. Niektórzy mogą się nie zgadzać:

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

ORYGINALNY:

Wiem, że jestem trochę spóźniony na przyjęcie tutaj, ale święty dym ...

Przechodząc prosto do sedna, ten rodzaj powiela wcześniejszą odpowiedź, ale jeśli naprawdę chcesz wykonać wspólną akcję dla kilku typów wyjątków i utrzymać całość w porządku w ramach jednej metody, dlaczego po prostu nie użyć lambda / closure / inline funkcja zrobić coś takiego: Mam na myśli całkiem spore szanse, że zdasz sobie sprawę, że po prostu chcesz, aby to zamknięcie było odrębną metodą, z której możesz korzystać wszędzie. Ale wtedy będzie to bardzo łatwe, bez faktycznej zmiany reszty kodu strukturalnie. Dobrze?

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

Nie mogę przestać się zastanawiać ( ostrzeżenie: trochę ironii / sarkazmu przed nami), dlaczego, do licha, podejmujesz te wszystkie wysiłki, aby po prostu zastąpić następujące:

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

... z pewną szaloną odmianą tego następnego zapachu kodu, mam na myśli tylko po to, by udawać, że oszczędzasz kilka naciśnięć klawiszy.

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

Ponieważ z pewnością nie jest automatycznie bardziej czytelny.

To prawda, zostawiłem trzy identyczne przypadki z /* write to a log, whatever... */ return;pierwszego przykładu.

Ale o to mi chodzi. Wszyscy słyszeliście o funkcjach / metodach, prawda? Poważnie. Napisz wspólną ErrorHandlerfunkcję i wywołaj ją z każdego bloku catch.

Jeśli zapytasz mnie, drugi przykład (ze słowami kluczowymi ifi is) jest zarówno znacznie mniej czytelny, a jednocześnie znacznie bardziej podatny na błędy podczas fazy konserwacji twojego projektu.

Faza konserwacji, dla każdego, kto może być stosunkowo nowy w programowaniu, będzie stanowić 98,7% lub więcej całkowitego czasu życia twojego projektu, a biedny schmuck wykonujący konserwację prawie na pewno będzie kimś innym niż ty. I jest bardzo duża szansa, że ​​spędzą 50% swojego czasu na pracy przeklinając twoje imię.

I oczywiście FxCop szczeka na ciebie, więc musisz również dodać atrybut do swojego kodu, który ma dokładnie zip związany z działającym programem, i jest tylko po to, aby powiedzieć FxCop, aby zignorował problem, który w 99,9% przypadków jest całkowicie poprawne w oznaczaniu. I przepraszam, mogę się mylić, ale czy ten atrybut „ignoruj” nie jest tak naprawdę wkompilowany w twoją aplikację?

Czy umieszczenie całego iftestu w jednym wierszu uczyniłoby go bardziej czytelnym? Nie wydaje mi się To znaczy, już dawno temu inny programista gwałtownie argumentował, że umieszczenie większej ilości kodu w jednym wierszu sprawiłoby, że „działałby on szybciej”. Ale oczywiście był niesamowitym wariatem. Próba wyjaśnienia mu (z prostą twarzą - co było wyzwaniem), w jaki sposób interpreter lub kompilator podzieliłby tę długą linię na dyskretne instrukcje składające się z jednej instrukcji na linię - zasadniczo identyczny z wynikiem, gdyby poszedł naprzód i po prostu sprawił, że kod był czytelny, zamiast próbować sprytnie skompilować kompilator - nie miał na niego żadnego wpływu. Ale dygresję.

O ile mniej jest to czytelne, gdy dodasz trzy kolejne typy wyjątków, za miesiąc lub dwa od teraz? (Odpowiedź: robi się o wiele mniej czytelny).

Jednym z głównych punktów jest to, że większość formatowania tekstowego kodu źródłowego, na który wszyscy patrzymy każdego dnia, polega na tym, aby uświadomić innym ludziom, co tak naprawdę dzieje się podczas działania kodu. Ponieważ kompilator zamienia kod źródłowy w coś zupełnie innego i nie obchodzi go styl formatowania kodu. Więc też wszystko w jednej linii jest do kitu.

Tylko mówię...

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

Jak zauważyli inni, ifw bloku catch możesz umieścić instrukcję, aby ustalić, co się dzieje. C # 6 obsługuje filtry wyjątków, więc następujące funkcje będą działać:

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

MyFilterMetoda może wtedy wyglądać następująco:

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

Alternatywnie można to wszystko zrobić w wierszu (prawa strona instrukcji when musi być tylko wyrażeniem logicznym).

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

Różni się to od używania ifinstrukcji z catchbloku, użycie filtrów wyjątków nie rozwinie stosu.

Możesz pobrać Visual Studio 2015, aby to sprawdzić.

Jeśli chcesz kontynuować korzystanie z programu Visual Studio 2013, możesz zainstalować następujący pakiet nuget:

Zainstaluj pakiet Microsoft.Net.Compilers

W momencie pisania tego tekstu będzie to obejmować obsługę C # 6.

Odwołanie do tego pakietu spowoduje zbudowanie projektu przy użyciu określonej wersji kompilatorów C # i Visual Basic zawartych w pakiecie, w przeciwieństwie do dowolnej wersji zainstalowanej w systemie.

Niestety nie w C #, ponieważ potrzebujesz do tego filtru wyjątków, a C # nie ujawnia tej funkcji MSIL. VB.NET ma jednak taką możliwość, np

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

Możesz użyć anonimowej funkcji do enkapsulacji kodu błędu, a następnie wywołać go w tych konkretnych blokach catch:

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

Ze względu na kompletność, od .NET 4.0 kod można przepisać jako:

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

TryParse nigdy nie zgłasza wyjątków i zwraca false, jeśli format jest niepoprawny, ustawiając WebId na Guid.Empty.

Od wersji C # 7 można uniknąć wprowadzania zmiennej w osobnym wierszu:

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

Możesz także utworzyć metody analizowania zwracanych krotek, które nie są jeszcze dostępne w .NET Framework od wersji 4.6:

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

I użyj ich w ten sposób:

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

Następna bezużyteczna aktualizacja tej bezużytecznej odpowiedzi pojawia się, gdy dekonstrukcja parametrów wyjściowych jest zaimplementowana w C # 12. :)

Filtry wyjątków są teraz dostępne w wersji c # 6+. Możesz to zrobić

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

W wersji C # 7.0+ można to również połączyć z dopasowaniem wzorca

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

Jeśli możesz zaktualizować aplikację do C # 6, masz szczęście. Nowa wersja C # ma zaimplementowane filtry wyjątków. Możesz więc napisać to:

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

Niektórzy uważają, że ten kod jest taki sam jak

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

Ale nie jest. W rzeczywistości jest to jedyna nowa funkcja w języku C # 6, której nie można emulować we wcześniejszych wersjach. Po pierwsze, powtórzenie rzutu oznacza więcej narzutu niż pominięcie haczyka. Po drugie, nie jest semantycznie równoważny. Nowa funkcja zachowuje nienaruszony stos podczas debugowania kodu. Bez tej funkcji zrzut awaryjny jest mniej przydatny, a nawet bezużyteczny.

Zobacz dyskusję na ten temat w CodePlex . I przykład pokazujący różnicę .

Jeśli nie chcesz używać ifoświadczenie obrębie catchzakresów, w C# 6.0można użyć Exception Filtersskładni , która została już obsługiwany przez CLR w wersji Zapowiedzi ale istniała tylko w VB.NET/ MSIL:

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

Ten kod złapie Exceptiontylko wtedy, gdy jest to InvalidDataExceptionlub ArgumentNullException.

Właściwie można umieścić w zasadzie dowolny warunek w tej whenklauzuli:

static int a = 8;

...

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

Zauważ, że w przeciwieństwie do ifinstrukcji wewnątrz catchzakresu, Exception Filtersnie można wyrzucić Exceptions, a kiedy to zrobią lub gdy warunek nie zostanie spełniony true, następny catchwarunek zostanie oceniony:

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

Wyjście: ogólny połów.

Jeśli jest więcej niż jeden true Exception Filter- pierwszy zostanie zaakceptowany:

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

Wyjście: połów.

I jak widać w MSILkodzie, kod nie jest tłumaczony na ifinstrukcje, ale na Filtersi Exceptionsnie można go wyrzucić z obszarów oznaczonych Filter 1i, Filter 2ale filtr rzucający Exceptionnie powiedzie się, również ostatnia wartość porównania wypchnięta na stos przed endfilterpoleceniem określi sukces / awarię filtra ( Catch 1 XOR Catch 2 wykona się odpowiednio):

Również konkretnie Guidma tę Guid.TryParsemetodę.

Dzięki C # 7 odpowiedź od Michaela Stuma może zostać ulepszona przy zachowaniu czytelności instrukcji switch:

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

I z C # 8 jako wyrażeniem przełącznika:

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

Przyjęta odpowiedź wydaje się akceptowalna, z tym wyjątkiem, że CodeAnalysis / FxCop będzie narzekać na fakt, że wychwytuje ogólny typ wyjątku.

Wydaje się również, że operator „jest” może nieznacznie obniżyć wydajność.

CA1800: Nie przesyłaj niepotrzebnie poleceń „rozważ zamiast tego testowanie wyniku operatora„ jako ””, ale jeśli to zrobisz, będziesz pisać więcej kodu, niż gdyby każdy wyjątek był wychwytywany osobno.

Tak czy inaczej, oto co bym zrobił:

bool exThrown = false;

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

if (exThrown)
{
    // Something else
}

w C # 6 zalecanym podejściem jest użycie filtrów wyjątków, oto przykład:

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

To jest wariant odpowiedzi Matta (wydaje mi się, że jest to trochę czystsze) ... użyj metody:

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

    WebId = Guid.Empty;
}

Wszelkie inne wyjątki zostaną zgłoszone, a kod WebId = Guid.Empty;nie zostanie trafiony. Jeśli nie chcesz, aby inne wyjątki powodowały awarię programu, po prostu dodaj to PO pozostałych dwóch chwytaniach:

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

Odpowiedź Josepha Daigle'a jest dobrym rozwiązaniem, ale uważam, że następująca struktura jest nieco bardziej uporządkowana i mniej podatna na błędy.

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

    // Handle exception
}

Istnieje kilka zalet odwracania wyrażenia:

• Instrukcja zwrotu nie jest konieczna
• Kod nie jest zagnieżdżony
• Nie ma ryzyka zapomnienia zwrotów „rzut” lub „powrót”, które w rozwiązaniu Józefa są oddzielone od wyrażenia.

Można go nawet spakować do pojedynczej linii (choć niezbyt ładnej)

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

    // Handle exception
}

Edit: filtrowanie wyjątek w C # 6.0 pozwoli składni czystsze bit i jest wyposażony w szereg innych korzyści na każdym obecnym rozwiązaniu. (przede wszystkim pozostawiając stos bez szwanku)

Oto jak ten sam problem wyglądałby przy użyciu składni C # 6.0:

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

@Micheal

Nieznacznie zmieniona wersja twojego kodu:

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

Porównywanie ciągów znaków jest brzydkie i wolne.

Co powiesz na

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

Przestroga i ostrzeżenie: Kolejny miły, funkcjonalny styl.

To, co znajduje się w linku, nie odpowiada bezpośrednio na twoje pytanie, ale rozszerzenie go tak, aby wyglądało tak:

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

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

(Zasadniczo zapewnia kolejne puste Catchprzeciążenie, które zwraca się)

Ważniejsze pytanie brzmi: dlaczego . Nie sądzę, że koszt przeważa tutaj zysk :)

Aktualizacja 2015-12-15: Zobacz https://stackoverflow.com/a/22864936/1718702 dla C # 6. Jest czystszy i teraz jest standardem w języku.

Przeznaczony dla osób, które chcą bardziej eleganckiego rozwiązania wychwyciło jeden raz i odfiltrowało wyjątki, używam metody rozszerzenia, jak pokazano poniżej.

Miałem już to rozszerzenie w mojej bibliotece, pierwotnie napisane do innych celów, ale działało idealnie idealnie do typesprawdzania wyjątków. Plus, imho, wygląda na czystsze niż kilka ||stwierdzeń. Ponadto, w przeciwieństwie do zaakceptowanej odpowiedzi, wolę jawne przetwarzanie wyjątków, więc ex is ...zachowywało się niepożądane zachowanie, ponieważ klasy pozbawione są przypisywane do typów nadrzędnych).

Stosowanie

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

Rozszerzenie IsAnyOf.cs (Zobacz przykład pełnej obsługi błędów dla zależności)

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

Przykład pełnej obsługi błędów (kopiuj-wklej do nowej aplikacji konsoli)

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

Dwa przykładowe testy jednostek NUnit

Zachowanie dopasowania dla Exceptiontypów jest dokładne (tzn. Dziecko NIE JEST dopasowaniem dla żadnego z jego typów rodzicielskich).

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

Ponieważ czułem, że te odpowiedzi tylko dotknęły powierzchni, próbowałem kopać nieco głębiej.

Więc tak naprawdę chcielibyśmy zrobić coś, czego nie można skompilować, powiedz:

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

Powodem tego jest to, że nie chcemy, aby moduł obsługi wyjątków przechwytywał rzeczy, których potrzebujemy w dalszej części procesu. Jasne, możemy złapać wyjątek i sprawdzić „co”, co zrobić, ale bądźmy szczerzy, naprawdę tego nie chcemy. (FxCop, problemy z debuggerem, brzydota)

Dlaczego więc ten kod się nie skompiluje - i w jaki sposób możemy go zhakować w taki sposób, aby był?

Jeśli spojrzymy na kod, naprawdę chcielibyśmy przekazać połączenie. Jednak zgodnie z MS Partition II bloki obsługi wyjątków IL nie będą działać w ten sposób, co w tym przypadku ma sens, ponieważ oznaczałoby to, że obiekt „wyjątku” może mieć różne typy.

Lub, aby napisać to w kodzie, prosimy kompilator, aby zrobił coś takiego (cóż, nie jest to całkowicie poprawne, ale myślę, że jest to najbliższa możliwa rzecz):

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

Powód, dla którego nie zostanie skompilowany, jest dość oczywisty: jaki typ i wartość miałby obiekt „$ wyjątek” (które są tutaj przechowywane w zmiennych „e”)? Sposób, w jaki chcemy, aby kompilator sobie z tym poradził, to zwrócenie uwagi na to, że wspólnym typem podstawowym obu wyjątków jest „Wyjątek”, użyj tego, aby zmienna zawierała oba wyjątki, a następnie obsłuż tylko dwa wychwycone wyjątki. Sposób ten jest zaimplementowany w IL jako „filtr”, który jest dostępny w VB.Net.

Aby działało w języku C #, potrzebujemy zmiennej tymczasowej o poprawnym typie podstawowym „Wyjątek”. Aby kontrolować przepływ kodu, możemy dodać kilka gałęzi. Tutaj idzie:

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

Oczywiste wady tego polegają na tym, że nie możemy rzucić ponownie, i - szczerze mówiąc - że jest to dość brzydkie rozwiązanie. Brzydotę można nieco naprawić, wykonując eliminację gałęzi, co sprawia, że ​​rozwiązanie jest nieco lepsze:

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

To pozostawia tylko „powtórkę”. Aby to zadziałało, musimy być w stanie wykonać obsługę wewnątrz bloku „catch” - a jedynym sposobem na wykonanie tej pracy jest złapanie obiektu „Exception”.

W tym momencie możemy dodać osobną funkcję, która obsługuje różne typy wyjątków za pomocą rozdzielczości przeciążenia lub obsługi wyjątku. Oba mają wady. Aby rozpocząć, oto sposób na zrobienie tego z funkcją pomocnika:

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

Drugim rozwiązaniem jest przechwycenie obiektu wyjątku i odpowiednio go obsłużyć. Najbardziej dosłowne tłumaczenie tego, oparte na powyższym kontekście, jest następujące:

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

Podsumowując:

• Jeśli nie chcemy ponownie rzucać, możemy rozważyć złapanie odpowiednich wyjątków i przechowywanie ich tymczasowo.
• Jeśli program obsługi jest prosty i chcemy ponownie użyć kodu, najlepszym rozwiązaniem jest prawdopodobnie wprowadzenie funkcji pomocnika.
• Jeśli chcemy przerzucić, nie mamy innego wyjścia, jak umieścić kod w module obsługi przechwytywania „Wyjątków”, który złamie FxCop i nieprzechwycone wyjątki twojego debuggera.

Jest to klasyczny problem, z którym ostatecznie musi się zmierzyć każdy programista C #.

Pozwól, że podzielę twoje pytanie na 2 pytania. Pierwszy,

Czy mogę wyłapać wiele wyjątków jednocześnie?

Krótko mówiąc, nie.

Co prowadzi do następnego pytania

Jak uniknąć pisania zduplikowanego kodu, biorąc pod uwagę, że nie mogę złapać wielu typów wyjątków w tym samym bloku catch ()?

Biorąc pod uwagę konkretną próbkę, w której wartość rezerwowa jest tania w budowie, lubię wykonywać następujące kroki:

1. Zainicjuj WebId do wartości rezerwowej.
2. Zbuduj nowego Guida w zmiennej tymczasowej.
3. Ustaw WebId na w pełni skonstruowaną zmienną tymczasową. Uczyń to końcową instrukcją bloku try {}.

Kod wygląda więc tak:

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

Jeśli zostanie zgłoszony jakikolwiek wyjątek, WebId nigdy nie jest ustawiany na półkonstruowaną wartość i pozostaje Guid.Empty.

Jeśli konstruowanie wartości rezerwowej jest drogie, a resetowanie wartości jest znacznie tańsze, wówczas przestawiłbym kod resetowania na własną funkcję:

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

Więc powtarzasz dużo kodu w ramach każdego przełącznika wyjątków? Wygląda na to, że wyodrębnienie metody byłoby dobrym pomysłem, prawda?

Twój kod sprowadza się do tego:

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

Zastanawiam się, dlaczego nikt nie zauważył takiego powielania kodu.

Od C # 6 masz ponadto filtry wyjątków, o których wspominali już inni. Możesz więc zmodyfikować powyższy kod do tego:

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

Chciałem dodać moją krótką odpowiedź do tego już długiego wątku. Coś, co nie zostało wspomniane, to kolejność pierwszeństwa instrukcji catch, a dokładniej musisz być świadomy zakresu każdego rodzaju wyjątku, który próbujesz złapać.

Na przykład, jeśli użyjesz wyjątku „catch-all” jako wyjątku , będzie on poprzedzał wszystkie inne instrukcje catch i oczywiście wystąpią błędy kompilatora, jednak jeśli odwrócisz kolejność, możesz połączyć swoje instrukcje catch (trochę anty-wzorca) ) możesz umieścić typ wyjątku typu catch-all na dole, co spowoduje przechwycenie wyjątków, które nie spełniały wyższych wymagań w bloku 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);
            }

Bardzo polecam ludziom przejrzenie tego dokumentu MSDN:

Hierarchia wyjątków

Może postaraj się uprościć kod, na przykład wstawiając wspólny kod do metody, tak jak w każdej innej części kodu, która nie znajduje się w klauzuli catch?

Na przykład:

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

// ...

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

Tak jak bym to zrobił, próba znalezienia prostoty jest pięknym wzorem

Zauważ, że znalazłem jeden sposób, aby to zrobić, ale to bardziej przypomina materiał do The Daily WTF :

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

Warto tu wspomnieć. Możesz odpowiedzieć na wiele kombinacji (błąd wyjątku i komunikat wyjątku).

Natknąłem się na scenariusz przypadku użycia, gdy próbowałem rzutować obiekt kontrolny w siatce danych, z zawartością jako TextBox, TextBlock lub CheckBox. W tym przypadku zwrócony wyjątek był taki sam, ale komunikat był różny.

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
} 

Chcę zasugerować najkrótszą odpowiedź (jeszcze jeden funkcjonalny styl ):

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

W tym celu należy utworzyć kilka przeciążeń metody „Catch”, podobnych do 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));
    }

i tak wiele, ile chcesz. Ale musisz to zrobić raz i możesz użyć go we wszystkich swoich projektach (lub, jeśli stworzyłeś pakiet nuget, my też moglibyśmy go użyć).

I wdrożenie 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 Nie sprawdziłem null pod kątem prostoty kodu, rozważ dodanie walidacji parametrów.

ps2 Jeśli chcesz zwrócić wartość z catch, musisz wykonać te same metody Catch, ale z parametrami return i Func zamiast Action.

Wystarczy zadzwonić do try i catch dwa razy.

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

To jest takie proste !!

W wersji c # 6.0 Filtry wyjątków to ulepszenia w zakresie obsługi wyjątków

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