Как программист Java, который хочет улучшить свои навыки программирования, я часто сталкиваюсь с ситуациями, которые я должен создать исключение во время выполнения. Я знаю, что это хорошая практика, если вы используете мудро.
Лично NullPointerException и IllegalStateException наиболее часто используются в созданных нами программных средствах. Как насчет вас?
Какие исключения во время выполнения вы часто используете? В каких ситуациях вы их используете?
Я никогда не бросаю NullPointerException. Для меня это выглядит естественно в коде, когда что-то идет не так, и для этого требуется, чтобы разработчик посмотрел, что происходит. Затем (s) он исправляет причину, и это не повторится.
Я использую IllegalStateException, чтобы сигнализировать, что объект настроен неправильно или что вызовы находятся в неправильном порядке. Однако мы все знаем, что в идеале объект должен гарантировать, что он не может находиться в плохом состоянии и что вы не можете вызвать его в неправильном порядке (создайте конструктор и результирующий объект...).
Я использую много IllegalArgumentException, когда метод обнаруживает, что его параметры неверны. Это несет ответственность любой публичный метод, чтобы прекратить обработку (чтобы избежать косвенных ошибок, которые труднее понять). Кроме того, несколько if в начале метода служат цели документации (документация, которая никогда не расходится с кодом, потому что это код:-)).
public void myMethod(String message, Long id) {
if (message == null) {
throw new IllegalArgumentException("myMethod message can't be null");
// The message doesn't log the argument because we know its value, it is null.
}
if (id == null) {
throw new IllegalArgumentException("myMethod id can't be null");
// This case is separated from the previous one for two reasons :
// 1. to output a precise message
// 2. to document clearly in the code the requirements
}
if (message.length()<12) {
throw new IllegalArgumentException("myMethod message is too small, was '" + message + "'");
// here, we need to output the message itself,
// because it is a useful debug information.
}
}
Я также использую конкретные исключения времени выполнения, чтобы сигнализировать об исключительных условиях более высокого уровня.
Например, если не удалось запустить модуль моего приложения, у меня может возникнуть исключение ModuleNotOperationalException (в идеале - общий код, например, перехватчик, в противном случае - конкретный код), когда другой модуль вызывает его. После этого архитектурного решения каждый модуль должен иметь дело с этим исключением при операциях, которые вызывают другие модули...
Я всегда считал, что исключения во время выполнения должны представлять ошибки программирования (например, null ссылка передана, когда не ожидается, индекс массива за пределами границ и т.д.), а проверенные исключения должны представлять исключительные условия в среде, которые не могут быть " (например, IOException, SQLException).
Одно из таких нарушений заключается в том, что иногда вам нужно обернуть то, что должно быть проверенным исключением в RuntimeException, чтобы удовлетворить определение интерфейса. В качестве краткого примера у вас может быть некоторая реалистичная реализация java.util.List, которая управляет распределенным списком между несколькими машинами. Очевидно, что это исключало бы проверенные исключения (возможно, некоторый подкласс IOException), если они определены сами по себе, но преимущества создания этого класса List заключаются в том, что клиенты могут использовать его почти прозрачно, везде, где они используют другой список.
Это может привести к тому, что Joel означает пропущенную абстракцию, поэтому важно, чтобы в вашей документации было ясно, какие исключения могут быть выброшены и что они означают! В этом случае я обнаруживаю, что пользовательский подкласс RuntimeException, как правило, более ясен при передаче основной причины, а не пытается перевести его в существующий класс исключений среды выполнения.
Я использую IllegalArgumentException относительно часто. В большинстве случаев я попытаюсь вернуть значение по умолчанию, как только это будет логично, но в то время, когда это не так, и поэтому я использую этот.
Другим, который я использую, является ArrayIndexOutOfBoundsException.
Неизвестное исключение, очень полезно: P
Мне также нравится org.apache.commons.lang.NotImplementedException
В основном я не бросаю исключение во время выполнения. Вместо того, чтобы проверять определенные условия, вы можете исключить определенные пользователем исключения. Но те немногие, что я использовал, IllegalAccessException, ArithmeticException, NumberFormatException и SecurityException.
Согласно Джошуа Блоху в Эффективной Java,
Наиболее часто повторяющиеся исключения: