Почему Catch (Exception) почти всегда является плохой идеей?

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Следовательно, вы должны улавливать исключения:

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

Ответ 5

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

Но иногда вам может понадобиться обрабатывать все исключения таким же образом. В таких случаях catch (Exception) может быть в порядке. Например:

    try
    {
        DoSomething();
    }
    catch (Exception e)
    {
        LogError(e);
        ShowErrorMessage(e); // Show "unexpected error ocurred" error message for user.
    }

Ответ 6

Это может быть java specific:

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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