Лучшие практики для отлова и повторного выброса исключений .NET

Какую наилучшую практику следует учитывать при отлове исключений и повторном их отбрасывании? Я хочу убедиться, что Exceptionобъект InnerExceptionи трассировка стека сохранены. Есть ли разница между следующими блоками кода в способе их обработки?

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

Vs:

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

Способ сохранения трассировки стека заключается в использовании параметра 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

Методика, предложенная ниже, была предложена Антоном Тихым в ответ на In 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объект. Это заставляет вас быть немного умнее с исключениями; другими словами, у вас должен быть явный улов для a, SqlExceptionчтобы ваш код обработки не делал что-то не так с a NullReferenceException.

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

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

Ссылайтесь на это, http://weblogs.asp.net/bhouse/archive/2004/11/30/272297.aspx

В основном MSIL (CIL) имеет две инструкции - «throw» и «rethrow»:

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

По сути, я вижу причину, по которой «throw ex» переопределяет трассировку стека.

Никто не объяснил разницу между 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» и «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 () вызвал исключение.