Почему я не могу написать просто попытку без улова или, наконец,?

Иногда я делаю это, и я видел, как другие делали это тоже:

VB:

Try
    DontWannaCatchIt()
Catch
End Try

С#:

try 
{ 
    DontWannaCatchIt();
} 
catch {}

Я знаю, что я должен поймать каждое важное исключение , которое я ожидаю, и что-то сделать, но иногда это не важно - или я делаю что-то неправильно?

Является ли это использование блока try некорректным, а требование хотя бы одного catch или finally блокировать его индикацию?

Обновление:

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

К счастью для меня, я кодирую в VB, поэтому могу написать его только одним catch:

Catch ex As Exception When TypeOf ex Is IOException _
                    OrElse TypeOf ex Is ArgumentException _
                    OrElse TypeOf ex Is NotSupportedException _
                    OrElse TypeOf ex Is SecurityException _
                    OrElse TypeOf ex Is UnauthorizedAccessException
    'I don't actually care.
End Try

Ответ 1

Если вы не хотите его поймать, почему вы используете try в первую очередь?

A try означает, что вы считаете, что что-то может пойти не так, и catch говорит, что вы можете адекватно обрабатывать то, что идет не так.

Итак, в вашей оценке:

try
{
    //Something that can go wrong
}
catch
{
    //An empty catch means I can handle whatever goes wrong. If a meteorite hits the
    //datacenter, I can handle it.
}

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

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

try
{
    //Something that could throw MeteoriteHitDatacenterException
}
catch (MeteoriteHitDatacenterException ex)
{
    //Please log when you're just catching something. Especially if the catch statement has side effects. Trust me.
    ErrorLog.Log(ex, "Just logging so that I have something to check later on if this happens.")

}

Ответ 2

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

Но вы должны разрешить распространение таких выражений, как StackOverflowException и OutOfMemoryException. Или, чаще, NullReferenceException. Эти исключения, как правило, являются ошибками, которые вы не ожидали, не можете восстановить, не должны восстанавливаться и не должны быть подавлены.

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

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

try
{
}
// I don't care about exceptions.
catch
{
}
// Okay, well, except for system errors like out of memory or stack overflow.
// I need to let those propagate.
catch (SystemException exception)
{
    // Unless this is an I/O exception, which I don't care about.
    if (exception is IOException)
    {
        // Ignore.
    }
    else
    {
        throw;
    }
}
// Or lock recursion exceptions, whatever those are... Probably shouldn't hide those.
catch (LockRecursionException exception)
{
    throw;
}
// Or, uh, what else? What am I missing?
catch (???)
{
}

Ответ 3

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

Ответ 4

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

Если вам нужно игнорировать все исключения, я не понимаю, почему вы не можете использовать try/catch таким образом.

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Нет блока catch = неопределенное состояние. Куда должен идти код? Что делать?

Пустой блок catch = ошибка, обработанная игнорированием.

Примечание: VBA имеет подлый "On Error Continue"...

Ответ 8

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

Ответ 9

что, если вы пишете только код с помощью try

try
{
   int j =0;
   5/j;
}

это эквивалентно записи

 int j =0;
   5/j;

так что попытка записи не имеет никакого смысла, она только увеличивает количество строк.

теперь, если вы пишете try с пустым catch или, наконец, вы явно указываете, что время выполнения должно вести себя по-другому.

так что "почему я думаю, что пустой блок try невозможен.

Ответ 10

Да, это неверно. Это похоже на goto: один на 100 KLoc в порядке, но если вам нужно много из них, вы делаете это неправильно.

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

try  
{      
   DontWannaCatchIt(); 
}  
catch 
{
    // This exception is ignored based on Spec Ref. 7.2.a,
    // the user gets a failure report from the actual results, 
    // and diagnostic details are available in the event log (as for every exception)
}

Дальше-смотри:

Обработка ошибок - это аспект: в некоторых контекстах необходимо вызвать ошибку и развернуть стек вызовов (например, вы копируете файл, копия завершается с ошибкой).

Вызов одного и того же кода в другом контексте может потребовать отслеживания ошибки, но операция продолжения (например, копирование 100 файлов с журналом, указывающим, какие файлы не удались).

Даже в этом случае пустой обработчик улова ошибочен.

В большинстве языков нет другой прямой реализации, чем попытка + catch в цикле и создание журнала в обработчике catch. (Однако вы могли бы создать гибкий механизм mroe: иметь обработчик потокового потока, который может либо бросить, либо убрать сообщение. Однако взаимодействие с инструментами отладки страдает без непосредственной поддержки языка.)

Разумным вариантом использования будет реализация TryX() из X(), но это должно было бы вернуть рассматриваемое исключение.