Почему бы вам не объявить явно, что вы можете выбросить некоторые встроенные исключения в Java? - PullRequest
7 голосов
/ 09 февраля 2009

Я заметил с Integer.parseInt(), что вам не нужно окружать его попыткой catch или объявить, что метод может вызвать исключение, несмотря на то, что он "выбрасывает" NumberFormatException.

Почему мне не нужно явно перехватывать NumberFormatException или указывать, что мой метод его выбрасывает?

Ответы [ 4 ]

16 голосов
/ 09 февраля 2009

Потому что это исключение во время выполнения.

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

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

Вы можете прочитать больше о их здесь

На самом деле существует три вида исключений , только одно из них должно обрабатываться (в большинстве случаев)

7 голосов
/ 09 февраля 2009
         Throwable
         /      \
      Error    Exception
                /     \
           *checked*  RuntimeException
                            \
                         *unchecked*

См. Мышление в Java для хорошего объяснения исключений Checked против Unchecked.

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

6 голосов
/ 09 февраля 2009

NumberFormatException расширяет RuntimeException, вам не нужно явно обрабатывать все, что унаследовано от RuntimeException.

Другими исключениями RuntimeException являются такие вещи, как NullPointerException и IndexOutOfBoundsException. Это то, чего программист может избежать, и попытка / перехват этих типов исключений создаст довольно загроможденный код.

2 голосов
/ 09 февраля 2009

Просто длинный комментарий к ответу инструментария.

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

try {
    Something that throws an exception
} catch (Exception e) {}

Это худший случай. Прежде всего, они не регистрируют, что они ловят исключение. Это часто случается, и почти принудительно выполняется из-за очень глупых проверенных исключений, таких как в Thread.sleep (), он генерирует InterruptedException, который ДОЛЖЕН быть перехвачен, но в 99% случаев вам все равно, если вы его получили или нет .

В приведенном выше случае это усугубляется тем фактом, что люди, как правило, просто ловят «Исключение», если выбрасывается более одного броска. Это означает, что даже если выдается критическое непроверенное исключение, оно будет перехвачено и проигнорировано, что сделает практически невозможным поиск проблемы.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...