Броски или попытка поймать

Каково общее эмпирическое правило при принятии решения о добавлении в метод предложения throws или использовании try-catch?

Из того, что я прочитал сам, throws должны использоваться, когда вызывающий объект нарушил свой конец контракта (переданный объект), и try-catch должен использоваться, когда возникает исключение во время операции, выполняемой внутри метод. Это правильно? Если так, что должно быть сделано на стороне вызывающих абонентов?

PS: искал через Google и SO, но хотел бы получить четкий ответ на этот вопрос.

ОТВЕТЫ

Ответ 1

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

Ответ 2

В общем случае метод должен выдавать исключение вызывающей стороне, когда он не может обработать связанную проблему локально. Например, если метод должен читать из файла с заданным путем, IOExceptions не могут быть обработаны локально разумным способом. То же самое относится и к неверному вводу, добавляя, что мой личный выбор - бросить непроверенное исключение, такое как IllegalArgumentException в этом случае.

И он должен отловить исключение из вызываемого метода, если:

  • это то, что может быть обработано локально (например, попытка преобразовать входную строку в число, и если преобразование завершится неудачно, вместо этого вполне допустимо вернуть значение по умолчанию),
  • или его не следует выдавать (например, если исключение исходит от нижнего уровня, специфичного для реализации, детали реализации которого не должны быть видны вызывающей стороне - например, я не хочу показывать, что мой DAO использует Hibernate для сохранения моих сущностей, поэтому я ловлю все HibernateExceptions локально и преобразую их в свои собственные типы исключений).

Ответ 3

Мое личное правило для этого просто:

  • Могу ли я обработать его значимым образом (добавлено из комментария)? Поэтому введите код в try/catch. Под его обработкой я имею в виду информировать пользователя/восстанавливать из-за ошибки или, в более широком смысле, понимать, как это исключение влияет на выполнение моего кода.
  • В другом месте выбросьте его.

Примечание: этот ответ теперь является вики-сообществом, не стесняйтесь добавлять дополнительную информацию.

Ответ 4

Вот как я его использую:

Броски:

  • Вы просто хотите, чтобы код останавливался, когда возникает ошибка.
  • Хорошо с методами, которые подвержены ошибки, если определенные предпосылки не удовлетворены.

Try-Catch:

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

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

Ответ 5

Решение о добавлении предложения try-catch или throws в ваши методы зависит от того, как вы хотите (или имеете) обработать свое исключение ".

Как обрабатывать исключение - это широкий и далекий от тривиального вопроса ответ. Он включает в себя, в частности, решение о том, где обрабатывать исключение и какие действия необходимо реализовать в блоке catch. Фактически, как обрабатывать исключение должно быть глобальное дизайнерское решение.

Поэтому, отвечая на ваши вопросы, нет эмпирического правила.

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

Ответ 6

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

Ответ 7

Метод должен исключать только throws исключение, если он может создавать разумные гарантии, окружающие состояние объекта, любые параметры, переданные методу, и любые другие объекты, на которые действует метод. Например, метод, который, как предполагается, извлекает из коллекции элемент, который, как предполагается, содержится в нем, может throws проверять исключение, если элемент, который должен был существовать в коллекции, не работает. Вызывающий, который ловит это исключение, должен ожидать, что коллекция не содержит данный предмет.

Обратите внимание, что в то время как Java разрешает проверенным исключениям создавать пузырьки через метод, объявленный как исключающий исключения из соответствующих типов, такое использование обычно следует рассматривать как анти-шаблон. Представьте себе, например, что какой-то метод LookAtSky() объявляется как вызывающий FullMoonException, и ожидается, что он бросит его, когда Луна будет заполнена; предположим далее, что LookAtSky() вызывает ExamineJupiter(), который также объявляется как throws FullMoonException. Если a FullMoonException было выбрано ExamineJupiter(), и если LookAtSky() не поймал его и не обработал или не перевернул в какой-либо другой тип исключения, то код, который назвал LookAtSky, предположил бы исключение, был результатом Земная луна полна; он не знал бы, что один из лун Юпитера может быть виновником.

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

Ответ 8

Когда использовать что. Я много искал об этом. Там нет жесткого и быстрого правила.

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

Источник: книга SCJP 6 Кэти Сьерра

Ответ 9

Если вы используете try catch, когда возникает исключение, остальные коды будут выполняться.

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

Ответ 10

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

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

Надеюсь, это правильно :-)