Общее программирование путает в .NET при обрабатывании исключений? [закрытый]

Использование исключений для нормального управления потоком. Исключения должны быть исключительными. Если это хорошая / ожидаемая операция, используйте возвращаемые значения и т. Д.

Неправильно

try
{
   // Do something stupid
}
catch
{
   // ignore the resulting error because I'm lazy, and later spend
   // a week trying to figure out why my app is crashing all over
   // the place.
}

Лучше

try
{
    /// do something silly.
}
catch (InvalidOperationException ex)
{
    /// respond, or log it.
}
catch (Exception e)
{
    /// log it.
}

Повторное генерирование исключения с бессмысленным сообщением.

try
{
    ...
}
catch (Exception ex)
{
   throw new Exception("An error ocurred when saving database changes").
}

Вы не поверите, как часто я вижу, что подобный код работает в продакшене.

Забудьте устанавливать внутреннее исключение при повторном создании перехваченное исключение

try
{
    ...
}
catch (IOException ioException)
{
    throw new AppSpecificException("It was not possible to save exportation file.")
    // instead of
    throw new AppSpecificException("It was not possible to save exportation file.", ioException);
}

Когда я опубликовал этот ответ, я забыл упомянуть, что мы всегда должны учитывать, когда включать внутреннее исключение или нет из соображений безопасности. Как Эрик Липперт указал в другом ответе на эту тему , некоторые исключения могут предоставлять конфиденциальную информацию о деталях реализации сервера. Таким образом, если вызывающему, который будет обрабатывать исключение, не доверяют, не рекомендуется включать внутреннюю информацию об исключении.

Предполагая, что исключение, охватывающее множество сценариев, было чем-то конкретным. Реальным сценарием было веб-приложение, в котором обработка исключений всегда предполагала, что все ошибки были тайм-аутами сеанса, и регистрировалась и сообщала обо всех ошибках как тайм-аутах сеанса.

Другой пример:

try
{
     Insert(data);
}
catch (SqlException e)
{
   //oh this is a duplicate row, lets change to update
   Update(data);
}

Повторное генерирование исключений вроде этого:

try 
{ 
   // some code here
}
catch(Exception ex)
{
   // logging, etc
   throw ex;
}

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

try 
{ 
   // some code here
}
catch(Exception ex)
{
   // logging, etc
   throw;
}

Невозможность перехвата возможных исключений внутри обработчика catch. Это может привести к распространению неправильного исключения вверх.

Например:

try
{
    DoImportantWork();
}
catch
{
    Cleanup();        
    throw;
}

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

try
{
    DoImportantWork();
}
catch
{
    try
    {
        Cleanup();        
    }
    catch
    {
        // We did our best to clean up, and even that failed.
        // If you try to log this error, the logging may throw yet another Exception.
    }
    throw;
}

Неиспользование using на IDisposable объектах:

File myFile = File.Open("some file");
callSomeMethodWhichThrowsException(myFile);
myFile.Close();

myFile не закрывается до вызова финализатора myFile (что может быть никогда), потому что исключение было брошено до вызова myFile.Close().

Правильный способ сделать это -

using(File myFile = File.Open("some file"))
{
    callSomeMethodWhichThrowsException(myFile);
}

Это переводится компилятором в нечто вроде:

File myFile = File.Open("some file");
try
{
    callSomeMethodWhichThrowsException(myFile);
}
finally
{
    if(myFile != null)
        myFile.Dispose(); //Dispose() calls Close()
}

Таким образом, файл закрывается даже перед лицом исключений.

Для регистрации Exception.Message вместо Exception.ToString ()

Часто я вижу, как код регистрирует только сообщение об исключении, в то время как он должен регистрировать возврат метода ToString. ToString предоставляет гораздо больше информации об исключении, чем сообщение. Помимо сообщения, он включает такую ​​информацию, как внутреннее исключение и трассировку стека.

Никто не говорит о том, чтобы видеть такие пустые блоки catch, как эти ....

 try{  
      //do something
    }
catch(SQLException sqex){  
        // do nothing  
    }

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

 try{  
     //do something  

 }catch(SQLException sqex){  

     //do something else  
 }

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

try {
  // Do something.
} catch (Exception exc) {
  // Do something.
}

Вместо:

try {
  // Do something.
} catch (IOException exc) {
  // Do something.
}

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

Уловитель пустого:

//What's the point?
catch()
{}

Перебрасывание:

//Exceptions are for *adding* detail up the stack
catch (Exception ex)
{throw ex;}

Попытка поймать OutOfMemoryException или StackOverflowException - они приводят к завершению работы среды выполнения и, следовательно, к способу их перехвата из одного процесса ( или даже из среды CLR в целом?)

OutOfMemoryException: исключение, которое выдается, когда недостаточно памяти для продолжения выполнения программы.

«Начиная с .NET Framework версии 2.0, объект StackOverflowException не может быть перехвачен блоком try-catch, и соответствующий процесс завершается по умолчанию. Следовательно, пользователям рекомендуется писать свой код для обнаружения и предотвращения переполнения стека. . "