Утверждать хорошую практику или нет?
Действительно ли это - хорошая практика для использования, Утверждают для параметров функции для осуществления их законности. Я проходил исходный код Платформы Spring, и я заметил, что они используют Assert.notNull много. Вот пример
public static ParsedSql parseSqlStatement(String sql) {
Assert.notNull(sql, "SQL must not be null");}
Вот Другой:
public NamedParameterJdbcTemplate(DataSource dataSource) {
Assert.notNull(dataSource,
"The [dataSource] argument cannot be null.");
this .classicJdbcTemplate = new JdbcTemplate(dataSource);
}
public NamedParameterJdbcTemplate(JdbcOperations classicJdbcTemplate) {
Assert.notNull(classicJdbcTemplate,
"JdbcTemplate must not be null");
this .classicJdbcTemplate = classicJdbcTemplate;
}
К вашему сведению, Assert.notNull (не assert оператор), определяется в util классе следующим образом:
public abstract class Assert {
public static void notNull(Object object, String message) {
if (object == null) {
throw new IllegalArgumentException (message);
}
}
}
5 ответов
В принципе, утверждения не сильно отличаются от многих других проверок во время выполнения.
Например, Java связывает все обращения к массиву во время выполнения. Это делает работу немного медленнее? да. Это выгодно? Абсолютно! Как только происходит нарушение границы, генерируется исключение, и программист предупреждается о любой возможной ошибке! Поведение в других системах, в которых доступ к массивам не проверяется по привязке, НАМНОГО НЕПРЕДСКАЗУЕМО! (часто с плачевными последствиями!).
Утверждения, используете ли вы библиотеку или языковую поддержку, похожи по духу. Есть затраты на производительность, но оно того стоит. Фактически, утверждения даже более ценны, потому что они явные и передают концепции более высокого уровня.
При правильном использовании затраты на производительность и ценность могут быть минимизированы как для клиента (который обнаружит нарушения контракта раньше, чем позже), так и для разработчиков (поскольку контракт самодействующий и самодокументирующийся ), максимально.
Другой способ взглянуть на это - рассматривать утверждения как «активные комментарии». Нет никаких сомнений в том, что комментарии полезны, но они ПАССИВНЫ; вычислительно они ничего не делают. Формулируя некоторые концепции как утверждения вместо комментариев, они становятся АКТИВНЫМИ. На самом деле они должны удерживаться во время выполнения; нарушения будут выявлены.
Основываясь на руководстве Sun по утверждениям, вы должны не использовать утверждения для проверки аргументов в общедоступных методах.
Проверка аргументов обычно является частью опубликованных спецификаций (или контракта) метода, и эти спецификации должны соблюдаться независимо от того, разрешены или запрещены утверждения.
Да, это хорошая идея. Вы обеспечиваете контракт интерфейса или класса. Если есть нарушение договора, вы хотите его обнаружить как можно скорее. Чем дольше вы ждете, тем более непредсказуемыми могут быть результаты и тем сложнее будет диагностировать.
Когда вы явно проверяете это, вы также должны предоставить информационное сообщение, которое при просмотре в файле журнала может дать полезный контекст, который поможет найти основную причину или даже просто понять, что вы сделали неправильное предположение о том, что такое контракт. .
Эти утверждения предоставляются библиотекой и не совпадают со встроенным ключевым словом assert .
Здесь есть разница: утверждения assert не запускаются по умолчанию (они должны быть включены с помощью параметра -ea ), в то время как утверждения, предоставляемые Assert нельзя отключить.
На мой взгляд (чего бы это ни стоило), это такой же хороший метод проверки параметров, как и любой другой. Если бы вы использовали встроенные утверждения, как следует из названия вопроса, я бы возразил против этого на том основании, что необходимые проверки не должны быть устранены. Но этот способ является лишь сокращением для:
public static ParsedSql parseSqlStatement(String sql) {
if (sql == null)
throw new IllegalArgumentException("SQL must not be null");
...
}
... что всегда является хорошей практикой в общедоступных методах.
Встроенный стиль утверждений более полезен в ситуациях, когда условие всегда должно быть истинным, или для частных методов. В языковом руководстве , представляющем утверждения , есть несколько хороших рекомендаций, которые в основном являются тем, что я только что описал.
Да, это хорошая практика.
В случае Spring это особенно важно, потому что проверки проверяют настройки свойств и т. Д., Которые обычно поступают из файлов проводки XML. Другими словами, они проверяют конфигурацию веб-приложения. И если вы когда-нибудь будете заниматься серьезной разработкой на основе Spring, эти проверки сэкономят вам часы отладки, если вы сделаете глупую ошибку конфигурации.
Но обратите внимание, что существует БОЛЬШАЯ разница между библиотечным классом Assert и ключевым словом Java assert , которое используется для определения утверждения Java. Последняя форма утверждений может быть отключена во время запуска приложения и НЕ должна использоваться для проверок достоверности аргументов, которые вы всегда хотите выполнять. Ясно, что дизайнеры Spring считают, что отключать проверки работоспособности конфигурации веб-приложений было бы плохой идеей ... и я согласен.
UPDATE
В Java 7 (и более поздних версиях) класс java.util.Objects предоставляет удобный метод requireNonNull для проверки того, является ли аргумент null ] и вызвать исключение. Вы используете его так:
SomeType t = ...
SomeType tChecked = Objects.requireNonNull(t);
или
SomeType tChecked = Objects.requireNonNull(t, "t should be non-null");
Однако обратите внимание, что этот метод вызывает NullPointerException , а не IllegalArgumentException .