Это нормально, что я иногда опускаю свои исключения?

Question

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

Если у вас есть метод чего-то НЕКРИТИЧЕСКОГО, который вы не хотите мешать важному функционированию вашего приложения, обычно ли используется приемник ошибок, подобный этому?

Try 
    'do stuff.  not important if it fails.

Catch ex as exception
    'sink.  do nothing.
End Try

Если бы вы думали о найме меня, и вы читали часть моего кода и видели это ... не так ли?

Сет

EDIT Вот Это Да! Спасибо за ваши ответы. Я думаю, что консенсус заключается в том, что никогда не должно быть сделано, или это должно быть очень редко.

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

Но сегодня над проектом, над которым я работал, я работал со списком изменений и столкнулся с добавлением простой функции. (Если вы хотите знать ... это добавляет поддержку контекстного меню в поле Rich Text Box.)

В прилагаемой записке говорилось: «Если это займет больше 15 минут ... бросьте ее».

Поэтому я столкнулся с необходимостью добавить потенциально полезную функцию, но у меня нет времени, чтобы проверить, что она не нарушит работоспособность. Напомним, что наш обработчик исключений для этой системы ДОЛЖЕН иметь механизм для обработки и обработки или регистрации этих ошибок. Но что, если я работал над системой, в которой не было надежной системы обработки ошибок. Было бы хорошо, чтобы добавить эту функцию, и если происходит ошибка ... ничего не потеряно.

Это было моё мышление. Но я принял ваше послание близко к сердцу ... что в принципе это плохая идея.

Сет

Answer 1

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

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

В большинстве случаев проглатывание System.Exception или System.SystemException неизбежно скрывает дальнейшие проблемы во время выполнения.

Answer 2

Вы должны никогда скрыть Исключение . В любом случае, я могу нанять вас, но вы бы этого не сделали, пока работали на меня:)

Серьезно, однако, в Java (например) исключения используются для определенных случаев, которые вы можете игнорировать, например FileNotFoundException (как вы это сделали с комментарием). Но если вы когда-нибудь поймете тип исключения - например, IOException - вы не сможете просто его скрыть. Если исключение ничего не значит для вас, оберните его в RuntimeException и скажите его клиенту.

Где-то по пути, Exception должен обрабатываться, но никогда не скрываться.

Answer 3

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

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

Answer 4

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

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

«Исключения» означает «исключения», а не сбой или ошибка. Что я имею в виду: если функция должен признать, что ввод может быть не правильным, я ожидаю, что функция делает НЕ используйте исключения. Мой гнев нацелен прежде всего на "ParseException".

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

Почему?

• Исключение нарушает поток управления
• Исключение является медленным
• Часто это все равно не имеет значения, поскольку вы инициализируете значениями по умолчанию.

Если вы вызываете функцию parseFunction несколько тысяч или миллионов (!) Раз, вы забиваете свой файл журнала на точно ничего.

Напротив, моя идеальная функция возвращает объект класса с кодом состояния и сообщение типа

StatCode stat = parseXYZ(Reader r);

, который затем можно проверить.

if (stat.code != OK)  
  //whatever

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

Answer 5

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

Answer 6

Лично я считаю это невероятно плохой практикой.

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

1. В настоящий момент вы на 100% уверены, что это исключение никогда не будет иметь значения?
2. Вы также на 100% уверены, что любое исключение, возникшее здесь в будущем, никогда не будет иметь значения, независимо от того, как будет развиваться кодовая база?
3. Даже если 1 и два являются истинными, неужели так сложно поставить здесь запись?

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

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

Answer 7

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

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

Это моя мысль ...

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

Answer 8

Нет, на мой взгляд, это не так.

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

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

Answer 9

Рекомендации по обработке исключений (MSDN) :

В соответствии с ними вы можете либо

Сделайте что-нибудь с ошибкой или проигнорируйте ее.

Думаю, решать вам и вашей команде.

Answer 10

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