Почему хорошие программисты иногда молча проглатывают исключения?

Question

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

Другими словами, это плохо, но почему хорошие программисты в редких случаях используют его?

try
{
    //Some code
}
catch(Exception){}

Answer 1

Я сделал это, когда есть какой-то фрагмент кода, где, несмотря на неудачу, я хочу, чтобы программа продолжалась.Например, я открыл необязательный файл журнала, и независимо от того, почему он не работал, я хочу продолжить выполнение программы.

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

Я сделал это для программ, которые должны запускаться один раз, чтобы преобразовать некоторые данные или что-то просто, чтобы выключить компилятор.Это совершенно другая ситуация для любой формы производственного кода.

В принципе, для этого нет веской причины, кроме лени.

Answer 2

как минимум записать его в окно вывода

try
{ }
catch (exception ex)
{
System.Diagnostics.Debug.Writeline(" exception in method so and so : " ex.message);
}

Answer 3

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

Answer 4

Может быть, потому что он не поймает, но все равно должен быть в состоянии. Однако я не могу придумать причину, по которой следует избегать какого-либо обработчика.

Answer 5

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

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

Другой пример может быть, где у вас есть альтернативные способы обработки ситуаций, например:

private Boolean SomeMethod() {
   Boolean isSuccessful = false;
   try {
      // call API function that throws one of several exceptions on failure.
      isSuccessful = true;
   } catch(Exception) { }

   return isSuccessful;
}

В приведенном выше примере у вас может не быть позиции возврата, но вы не хотите, чтобы она фильтровалась. Это нормально для методов SHORT, где возвращаемое значение устанавливается только в успешное состояние как последний шаг в блоке try.

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

Answer 6

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

Answer 7

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

Исключения никогда не должны быть съедены без какого-либо повторного броска, регистрации или даже комментария, объясняющего, почему исключение было съедено молча.В мои ранние годы я часто ел исключения, если бы знал, что я единственный человек, работающий над кодом.Конечно, когда придет время пересмотреть код, я забуду, что на самом деле означает это исключение, и мне придется перепроверять все, чтобы понять это снова.

Answer 8

Как насчет выполнения обновления контроля выполнения?Я обновил переменные состояния, используемые процедурой отрисовки элемента управления, поэтому при следующем отрисовке элемента управления будет отображаться правильное состояние.Затем я выполняю:

  Try
    MyControl.BeginInvoke(MyControlUpdateDelegate);
  Catch Ex as Exception
  End Try

Если элемент управления все еще существует, он будет обновлен.Если он будет утилизирован, мне все равно, будет ли он обновляться или нет.Если элемент управления не удален, но не может быть обновлен по какой-либо другой причине, мне все равно будет все равно, будет ли он обновлен или нет, потому что я все равно не способен сделать что-нибудь разумное с этим.

Обратите внимание, что я мог бы добавить «If Not MyControl.IsDisposed Then ...», но это просто добавило бы работу в общий случай и не предотвратило бы возникновение исключения, если элемент управления будет удален во время BeginInvoke.

Answer 9

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