Какой из них является лучшей практикой [дублировать]

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

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

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

Поэтому вы должны улавливать исключения:

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

Я нахожу два приемлемых использования catch (Exception): - На верхнем уровне приложения (непосредственно перед возвратом пользователю). Таким образом, вы можете предоставить адекватное сообщение. - Использование его для маскировки исключений низкого уровня для бизнес-процессов.

Первый случай является самоочевидным, но позвольте мне развить второе:

Doing:

try {
    xxxx
} catch(Exception e) {
    logger.error("Error XXX",e)
}

- это маскировка ошибок, например @dimitarvp.

Но

try {
    xxxx
} catch(Exception e) {
    throw new BussinessException("Error doing operation XXX",e)
}

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

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

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

Если в блоке кода вы можете получить SQLException и NetworkException, вы должны поймать их и предоставить адекватные сообщения и для каждого из них. Но если в конце блока try / catch у вас есть Exception, сопоставляющее его с BussinessException, это нормально для меня. Фактически, я нахожу адекватным, что более высокие уровни обслуживания только бросают бизнес-исключения (с деталями внутри).

Но иногда все в порядке! Например, если у вас есть фрагмент кода, который делает что-то «лишнее», что вам действительно неинтересно, и вы не хотите, чтобы оно взорвало ваше приложение. Например, недавно я работал над большим приложением, когда наши деловые партнеры хотели, чтобы определенная ежедневная транзакция была суммирована в новом файле журнала. Они объяснили, что журнал не так важен для них и что он не квалифицируется как требование. Это было что-то дополнительное, что помогло бы им понять обрабатываемые данные. Они им не нужны, потому что они могли получить информацию в другом месте. Таким образом, это редкий случай, когда прекрасно поймать и проглатывать исключения.

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

Кроме того, что еще ответил @anthares:

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

Основной принцип состоит в том, чтобы поймать наиболее специфический тип, который вы можете.

catch(Exception) является плохой практикой, потому что он также ловит все исключение RuntimeException (исключенное исключение).