Najlepsze praktyki dotyczące wychwytywania i ponownego zgłaszania wyjątków .NET

Jakie najlepsze praktyki należy wziąć pod uwagę przy wychwytywaniu wyjątków i ponownym ich rzucaniu? Chcę się upewnić, że śledzenie Exceptionobiektu InnerExceptioni stosu są zachowane. Czy istnieje różnica między następującymi blokami kodu w sposobie, w jaki sobie z tym radzą?

try
{
    //some code
}
catch (Exception ex)
{
    throw ex;
}

Vs:

try
{
    //some code
}
catch
{
    throw;
}

Sposobem na zachowanie śladu stosu jest również użycie opcji throw;To jest poprawne

try {
  // something that bombs here
} catch (Exception ex)
{
    throw;
}

throw ex;jest w zasadzie jak zgłoszenie wyjątku od tego momentu, więc ślad stosu trafiałby tylko tam, gdzie wydaje się throw ex;instrukcję.

Mike ma również rację, zakładając, że wyjątek pozwala przekazać wyjątek (co jest zalecane).

Karl Seguin ma także świetne recenzje na temat obsługi wyjątków w swoich e-bookach programistycznych , co jest świetną lekturą.

Edycja: Link roboczy do Podstawy programowania pdf. Wystarczy wyszukać w tekście „wyjątek”.

Jeśli wyrzucisz nowy wyjątek z początkowym wyjątkiem, zachowasz również początkowy ślad stosu.

try{
} 
catch(Exception ex){
     throw new MoreDescriptiveException("here is what was happening", ex);
}

W rzeczywistości istnieją pewne sytuacje, w których throwstatystyka nie zachowa informacji StackTrace. Na przykład w poniższym kodzie:

try
{
  int i = 0;
  int j = 12 / i; // Line 47
  int k = j + 1;
}
catch
{
  // do something
  // ...
  throw; // Line 54
}

StackTrace wskaże, że wiersz 54 zgłosił wyjątek, chociaż został zgłoszony w wierszu 47.

Unhandled Exception: System.DivideByZeroException: Attempted to divide by zero.
   at Program.WithThrowIncomplete() in Program.cs:line 54
   at Program.Main(String[] args) in Program.cs:line 106

W sytuacjach takich jak ta opisana powyżej istnieją dwie opcje zachowania oryginalnego StackTrace:

Wywołanie wyjątku.InternalPreserveStackTrace

Ponieważ jest to metoda prywatna, należy ją wywołać za pomocą refleksji:

private static void PreserveStackTrace(Exception exception)
{
  MethodInfo preserveStackTrace = typeof(Exception).GetMethod("InternalPreserveStackTrace",
    BindingFlags.Instance | BindingFlags.NonPublic);
  preserveStackTrace.Invoke(exception, null);
}

Mam tę wadę, że polegam na prywatnej metodzie w celu zachowania informacji StackTrace. Można go zmienić w przyszłych wersjach .NET Framework. Powyższy przykład kodu i zaproponowane poniżej rozwiązanie zostało wyodrębnione z bloga internetowego Fabrice MARGUERIE .

Wywołanie wyjątku.SetObjectData

Poniższa technika została zasugerowana przez Anton Tykhyy jako odpowiedź na In C #, w jaki sposób mogę ponownie wprowadzić wyjątek wewnętrzny bez utraty pytania śledzenia stosu .

static void PreserveStackTrace (Exception e) 
{ 
  var ctx = new StreamingContext  (StreamingContextStates.CrossAppDomain) ; 
  var mgr = new ObjectManager     (null, ctx) ; 
  var si  = new SerializationInfo (e.GetType (), new FormatterConverter ()) ; 

  e.GetObjectData    (si, ctx)  ; 
  mgr.RegisterObject (e, 1, si) ; // prepare for SetObjectData 
  mgr.DoFixups       ()         ; // ObjectManager calls SetObjectData 

  // voila, e is unmodified save for _remoteStackTraceString 
} 

Chociaż ma tę zaletę, że polega wyłącznie na metodach publicznych, zależy to również od następującego konstruktora wyjątków (którego niektóre wyjątki opracowane przez strony trzecie nie implementują):

protected Exception(
    SerializationInfo info,
    StreamingContext context
)

W mojej sytuacji musiałem wybrać pierwsze podejście, ponieważ wyjątki podniesione przez bibliotekę innej firmy, z której korzystałem, nie implementowały tego konstruktora.

Kiedy to robisz throw ex, w zasadzie rzucasz nowy wyjątek i tracisz informacje o oryginalnym stosie śledzenia. throwjest preferowaną metodą.

Zasadą jest unikanie łapania i rzucania podstawowego Exceptionobiektu. To zmusza cię do nieco mądrzejszego podejścia do wyjątków; innymi słowy powinieneś mieć wyraźny haczyk SqlException, aby twój kod obsługi nie zrobił czegoś złego z NullReferenceException.

Jednak w prawdziwym świecie łapanie i rejestrowanie wyjątku podstawowego jest również dobrą praktyką, ale nie zapomnij przejść całej rzeczy, aby uzyskać jakąkolwiek InnerExceptions.

Zawsze powinieneś używać „rzut”; aby ponownie wprowadzić wyjątki w .NET,

Zobacz to, http://weblogs.asp.net/bhouse/archive/2004/11/30/272297.aspx

Zasadniczo MSIL (CIL) ma dwie instrukcje - „rzut” i „rzut”:

• C #'s „throw ex;” zostaje wkompilowany w „rzut” MSIL
• „Rzut” C # - w „rethrow” MSIL!

Zasadniczo widzę powód, dla którego „throw ex” przesłania ślad stosu.

Nikt nie wyjaśnił różnicy między ExceptionDispatchInfo.Capture( ex ).Throw()zwykłym throw, więc oto jest. Jednak niektórzy zauważyli problem throw.

Całkowitym sposobem na ponowne wyłapanie przechwyconego wyjątku jest użycie ExceptionDispatchInfo.Capture( ex ).Throw()(dostępne tylko w .Net 4.5).

Poniżej znajdują się przypadki niezbędne do przetestowania tego:

1.

void CallingMethod()
{
    //try
    {
        throw new Exception( "TEST" );
    }
    //catch
    {
    //    throw;
    }
}

2)

void CallingMethod()
{
    try
    {
        throw new Exception( "TEST" );
    }
    catch( Exception ex )
    {
        ExceptionDispatchInfo.Capture( ex ).Throw();
        throw; // So the compiler doesn't complain about methods which don't either return or throw.
    }
}

3)

void CallingMethod()
{
    try
    {
        throw new Exception( "TEST" );
    }
    catch
    {
        throw;
    }
}

4

void CallingMethod()
{
    try
    {
        throw new Exception( "TEST" );
    }
    catch( Exception ex )
    {
        throw new Exception( "RETHROW", ex );
    }
}

Przypadek 1 i przypadek 2 dają ślad stosu, w którym numerem kodu źródłowego dla CallingMethodmetody jest numer throw new Exception( "TEST" )wiersza.

Jednak przypadek 3 da ci ślad stosu, w którym numerem linii kodu źródłowego dla CallingMethodmetody jest numer linii throwwywołania. Oznacza to, że jeśli throw new Exception( "TEST" )linia jest otoczona innymi operacjami, nie masz pojęcia, pod którym numerem linii został zgłoszony wyjątek.

Przypadek 4 jest podobny do przypadku 2, ponieważ zachowany jest numer wiersza oryginalnego wyjątku, ale nie jest to rethrow, ponieważ zmienia typ pierwotnego wyjątku.

Kilka osób faktycznie pominęło bardzo ważny punkt - „rzut” i „rzut ex” mogą zrobić to samo, ale nie dają istotnej informacji, która jest linią, w której wystąpił wyjątek.

Rozważ następujący kod:

static void Main(string[] args)
{
    try
    {
        TestMe();
    }
    catch (Exception ex)
    {
        string ss = ex.ToString();
    }
}

static void TestMe()
{
    try
    {
        //here's some code that will generate an exception - line #17
    }
    catch (Exception ex)
    {
        //throw new ApplicationException(ex.ToString());
        throw ex; // line# 22
    }
}

Kiedy wykonujesz „rzut” lub „rzut ex”, otrzymujesz ślad stosu, ale linia # będzie miała numer 22, więc nie możesz dowiedzieć się, która linia dokładnie zgłasza wyjątek (chyba że masz tylko 1 lub kilka wiersze kodu w bloku try). Aby uzyskać oczekiwaną linię nr 17 w twoim wyjątku, musisz zgłosić nowy wyjątek z oryginalnym śledzeniem stosu wyjątków.

Możesz także użyć:

try
{
// Dangerous code
}
finally
{
// clean up, or do nothing
}

A wszelkie zgłoszone wyjątki zwiększą się do następnego poziomu, który je obsługuje.

Zdecydowanie użyłbym:

try
{
    //some code
}
catch
{
    //you should totally do something here, but feel free to rethrow
    //if you need to send the exception up the stack.
    throw;
}

To pozwoli zachować twój stos.

Do Twojej wiadomości Właśnie przetestowałem to i ślad stosu zgłoszony przez „throw”; nie jest całkowicie poprawnym śladem stosu. Przykład:

    private void foo()
    {
        try
        {
            bar(3);
            bar(2);
            bar(1);
            bar(0);
        }
        catch(DivideByZeroException)
        {
            //log message and rethrow...
            throw;
        }
    }

    private void bar(int b)
    {
        int a = 1;
        int c = a/b;  // Generate divide by zero exception.
    }

Ślad stosu poprawnie wskazuje na początek wyjątku (zgłaszany numer linii), ale numer linii zgłaszany dla foo () jest linią rzutu; instrukcja, stąd nie można powiedzieć, które z wywołań bar () spowodowało wyjątek.