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

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

См. эту статью Брайана Гетца (мастера параллелизма), у которого есть собственное понимание, а также цитируется Джош Блох в Effective Java

Здесь нет точек соприкосновения. Вы найдете две группы:

1. Те, кто ненавидят проверенные исключения, поймают и заключат их в какое-то исключение RuntimeException .

2. Те, кто ненавидят RuntimeException

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

Другая группа хочет увидеть, что может пойти не так. RuntimeException эффективно скрывает это.

Есть простое исправление, BTW: Make Exception extension RuntimException. Безумный? На самом деле, нет. Если вы сделаете это с JDK 7, вы получите две ошибки компиляции.

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

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

Если вы у меня под рукой есть книга Джоша Блоха «Эффективная Java», я знаю, что он довольно подробно описывает обработку исключений. В настоящее время у меня нет к нему доступа, поэтому я не могу его обобщить или дать вам ссылки на страницы, но я почти уверен, что у него есть веские аргументы в пользу того, чтобы не перехватить java.lang.Exception.

это длинная статья, но эта предлагает вам:

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

Теоретически, №1 (ожидаемые ошибки) должен иметь свой собственный тип исключения и единственное место, которое должно перехватывать # 2 (RuntimeException) - это некий тип обработчика верхнего уровня, который улавливает исключение, регистрирует его и показывает пользователю сообщение об ошибке, и даже здесь вам, вероятно, следует уловить Throwable, чтобы гарантировать обработку любых неперехваченных исключений.

Следуя этим рекомендациям, вы не должны перехватывать Exception, поскольку оно не соответствует ни одному из вышеперечисленных критериев (то есть, это не RuntimeException, аs не специализированный подкласс Exception для указания ожидаемой ошибки).

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

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

Вот кое-что: Совет по Java 134: при перехвате исключений не разбрасывайте сеть слишком широко (JavaWorld)

Эффективная Java (второе издание) Джошуа Блоха, возможно, есть что-то по этому поводу в главе 9 (Исключения), хотя я не смог быстро найти ничего о том, чтобы не перехватить Exception .

Вот вопросы и ответы от JavaWorld о вопрос (также указывает на Совет 134 по Java) - он также объясняет, почему иногда нужно нарушать правило не перехватывать Исключение или даже Throwable .

where they catch a subclass of java.lang.Exception, log an error, and rethrow the subclass as java.lang.Exception. I need to convince them that they need to stop writing code like this.

I agree they should use another tactic, but for different reasons. There's not much sense in catching an exception just to log it and rethrow it.

An alternative is: don't catch the exception and let some higher up code (like a Java EE Filter, or try/catch in your main() method) catch and log all uncaught exceptions. Then you ensure each exception is only logged once, and you know all uncaught exceptions will be logged.

If you need to add extra information to the exception, catch it, change the message and rethrow it. I usually use a RuntimeException for this:

} catch (Exception originalException) {
    throw new RuntimeException("user name was " + userName, originalException);
}