Java не проверено / проверено уточнение исключения - PullRequest
6 голосов
/ 21 февраля 2011

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

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

У меня такой вопрос, предположим, ради аргумента, у меня есть метод, который делит два числа

double divide(double numerator, double denominator)
{    return numerator / denominator;    }

и метод, который требует где-то деления

void foo()
{    double a = divide(b, c);    }

Кто отвечает за проверку случая, когда знаменатель равен нулю, и следует ли проверять или снимать исключение (игнорируя встроенные в Java проверки деления)?

Итак, будет ли объявлен метод деления как есть или как

double divide(double numerator, double denominator) throws DivideByZeroException
{
    if(denominator == 0) throw DivideByZeroException
    else ...
}

void foo()
{
    try{
        double a = divide(b, c);
    }
    catch(DivideByZeroException e)
    {}
}

или без проверенного исключения, как:

double divide(double numerator, double denominator)
{
    if(denominator == 0) throw DivideByZeroException
    else ...
}

void foo()
{
    if(c != 0)
       double a = divide(b, c);
}

и разрешить foo сделать проверку деления на ноль?

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

Ответы [ 6 ]

7 голосов
/ 21 февраля 2011

Интересная тема действительно!

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

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

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

Применительно к вашему примеру я подумаю: «Как это должно выглядеть для пользователя?»

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

На заметку: я никогда не выбрасываю DivideByZeroException и NullPointerException - я позволяю JVM бросать их для меня. В этом случае вы можете создать свой собственный класс исключений или использовать подходящее встроенное проверенное исключение.

1 голос
/ 22 февраля 2011

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

1 голос
/ 21 февраля 2011

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

  • java.lang.Exception - известный как проверенные исключения
  • java.lang.RuntimeException, известная как исключение UNchecked - как бонус java.land.RuntimeException расширяет java.lang.Exception (для облегчения обработки в catch блоках и не только)
  • java.lang.Error - ошибки,также непроверенный и редко должен обрабатываться кодом пользовательского пространства, но знание их и их различий является большим плюсом.К ним относятся (наиболее известные): ошибка связывания, переполнение стека, нехватка памяти, ошибки утверждения
  • java.lang.Throwable - Проверено! и источник всех исключений, немногие должны непосредственно подклассировать его,но некоторые делают это по неизвестным причинам

Так что нужно объявить исключения и позаботиться о правильном распространении (только на уровне компиляции), непроверенные распространяются автоматически, и разработчик не должен предоставлятьобработка, если в этом нет необходимости.

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

Худшие практики включают в себя: catch (Throwable t){}, по многим причинам, обычноошибки не должны обрабатываться, если в этом нет необходимости, и большинство ошибок обычно приводят к смерти потока в любом случае.

1 голос
/ 21 февраля 2011

Моя любимая дискуссия о разнице в философии между проверенными и непроверенными исключениями в Java:

http://www.javapractices.com/topic/TopicAction.do?Id=129

0 голосов
/ 22 февраля 2011

Никогда не бросайте явно RuntimeException с Если вы когда-либо думали, что вам нужно, просто дайте времени выполнения сделать это вместо использования throw.

0 голосов
/ 22 февраля 2011

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

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

...