Рекомендации по перехвату и повторному выбрасыванию исключений .NET

Способ сохранить трассировку стека - использовать throw; Это также верно

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

throw ex; в основном похож на выброс исключения из этой точки, поэтому трассировка стека будет идти только туда, где вы выдаете оператор throw ex;.

Майк также верен, если исключение позволяет передать исключение (которое Рекомендовано).

Карл Сегин имеет отличная статья об обработке исключений в его электронная книга по основам программирования, которую стоит прочитать.

Изменить: рабочая ссылка на Основы программирования pdf. Просто найдите в тексте «исключение».

Если вы создадите новое исключение с начальным исключением, вы также сохраните начальную трассировку стека.

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

На самом деле, есть некоторые ситуации, в которых throw статус не сохраняет информацию StackTrace. Например, в приведенном ниже коде:

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

StackTrace укажет, что в строке 54 возникло исключение, хотя оно возникло в строке 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

В ситуациях, подобных описанной выше, есть два варианта сохранить исходный StackTrace:

Вызов Exception.InternalPreserveStackTrace

Поскольку это частный метод, его нужно вызывать с помощью отражения:

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

У меня есть недостаток в том, что я полагаюсь на частный метод для сохранения информации StackTrace. Он может быть изменен в будущих версиях .NET Framework. Пример кода выше и предлагаемое ниже решение были извлечены из Журнал Fabrice MARGUERIE.

Вызов Exception.SetObjectData

Приведенный ниже метод был предложен Антоном Тихи в качестве ответа на В C #, как я могу повторно выбросить InnerException без потери трассировки стека вопрос.

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 
} 

Хотя он имеет то преимущество, что полагается только на общедоступные методы, он также зависит от следующего конструктора исключения (который не реализован в некоторых исключениях, разработанных третьими сторонами):

protected Exception(
    SerializationInfo info,
    StreamingContext context
)

В моей ситуации мне пришлось выбрать первый подход, потому что исключения, вызванные сторонней библиотекой, которую я использовал, не реализовали этот конструктор.

Когда вы throw ex, вы по существу генерируете новое исключение и пропускаете исходную информацию трассировки стека. throw - предпочтительный метод.

Практическое правило - избегать ловли и бросания базового Exception объекта. Это заставляет вас быть немного умнее в отношении исключений; другими словами, у вас должен быть явный улов для SqlException, чтобы ваш код обработки не сделал что-то неправильное с NullReferenceException.

Однако в реальном мире перехват и протоколирование базового исключения также является хорошей практикой, но не забывайте все это пройти, чтобы получить InnerExceptions, которое оно может иметь.

Никто не объяснил разницу между ExceptionDispatchInfo.Capture( ex ).Throw() и простым throw, так что вот оно. Однако некоторые люди заметили проблему с throw.

Полный способ повторно вызвать перехваченное исключение - использовать ExceptionDispatchInfo.Capture( ex ).Throw() (доступно только в .Net 4.5).

Ниже приведены примеры, необходимые для проверки:

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

Случай 1 и случай 2 предоставят вам трассировку стека, где номер строки исходного кода для метода CallingMethod - это номер строки строки throw new Exception( "TEST" ).

Однако вариант 3 предоставит вам трассировку стека, где номер строки исходного кода для метода CallingMethod является номером строки вызова throw. Это означает, что если строка throw new Exception( "TEST" ) окружена другими операциями, вы не знаете, на каком номере строки фактически было сгенерировано исключение.

Случай 4 аналогичен случаю 2, потому что номер строки исходного исключения сохраняется, но не является реальным повторным вызовом, поскольку он изменяет тип исходного исключения.

Вы всегда должны использовать "throw;" чтобы повторно выбросить исключения в .NET,

Обратитесь к этому, http://weblogs.asp.net/bhouse/archive/2004/11/30/272297.aspx

В основном MSIL (CIL) имеет две инструкции - «выбросить» и «перебросить»:

• C # "throw ex;" компилируется в "throw" MSIL
• C # "throw;" - в МСИЛ "перебросить"!

В принципе, я могу понять причину, по которой "throw ex" переопределяет трассировку стека.

Некоторые люди действительно упустили очень важный момент - 'throw' и 'throw ex' могут делать то же самое, но они не дают вам важной информации, которая является строкой, в которой произошло исключение.

Рассмотрим следующий код:

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

Когда вы выполняете либо 'throw', либо 'throw ex', вы получаете трассировку стека, но строка # будет # 22, поэтому вы не можете определить, какая именно строка выбрасывала исключение (если у вас только 1 или несколько строк кода в блоке try). Чтобы получить ожидаемую строку № 17 в вашем исключении, вам нужно будет создать новое исключение с исходной трассировкой стека исключений.

Вы также можете использовать:

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

И любые созданные исключения будут перемещаться на следующий уровень, который их обрабатывает.

Я бы определенно использовал:

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

Это сохранит ваш стек.

К вашему сведению, я только что проверил это и трассировку стека, о которой сообщает 'throw;' не совсем корректная трассировка стека. Пример:

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

Трассировка стека правильно указывает на источник исключения (указанный номер строки), но номер строки, сообщаемый для foo (), является строкой выброса; оператор, поэтому вы не можете сказать, какой из вызовов bar () вызвал исключение.