Это хорошо, что я иногда снижаю свои исключения?

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

Вы ожидаете очень конкретное исключение, и знаете, что вы можете восстановить из него:

try {
 Integer.Parse(someString);
}
catch (ParseException pe) {
 //In this particular use case, if the string doesn't parse, 
 //I don't need to do anything. Logging a warning might be a
 //good idea, in some cases
}

Вы делаете код очистки:

beginDatabaseTransaction();
try {
 doSomeDatabaseOperation();
}
catch (Exception e) {
 log.error(e); //log the original exception
 try {
  rollbackDatabaseConnection();
 }
 catch(Exception e2) {
  //You may ignore this one-off exception, though
  //I would strongly consider logging it
 }
 throw; //rethrow the original exception and let it propagate
}

(это без означает лучшую практику для операций с базой данных; просто надуманный пример.)

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

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

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

Начните с этого поста и перейдите по ссылкам. Или просто искать Носорога.

Если вы не возражаете против книги с финансовым откосом, моя первоначальная оценка Monte Carlo Frameworks: Building Customizable High-Performance C++ Applications очень позитивна.

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

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

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

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

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

try {
   Cache.refresh(myObject)
}
catch (NotInCacheException) {
   // If the object isn't already in the cache, then we don't have to worry 
   // about refreshing it. It's assumed that this is a common occurrence,
   // so we don't need to log it either; that ends up just spamming
   // the logs. So, just swallow it, silently.
}

(Примечание: должен ли cache.refresh () должен быть выбрасывать неотъемлемоеexeexception вообще не в выдаче здесь; я просто использую это как быстрый пример).

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

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

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

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

StatCode stat = parseXYZ(Reader r);

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

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

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

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

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

Я делаю это только на надоедливых отрывках вроде закрытия соединения:

try {
   conn.close()
}
catch( Exception e ) {
}

потому что я уже уверен, что оно мне больше не нужно.

Я бы сказал: "Не делай этого" - не так.

Прежде всего, попробуйте рефакторинг "некритичного" кода, чтобы он не бросал исключение.

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

. Если используют VS2008, вы можете хотя бы отправить их в окно отладки

 System.Diagnostics.Debug.WriteLine("exception in method - my method -: "+ex.message);

PHP имеет Domdocument для навигации на DOM. Я не слышал о том, чтобы выполнить JavaScript.

лучшие практики для обработки исключений (MSDN) :

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

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

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

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

Я бы не использовал структуру TRY CALL или Refactor код в методе, который возвращает логию, так что я, по крайней мере, могу определить, если он преуспеет или нет ...

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

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

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

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