2010-12-27 3 views
22

Я знаю, что ключевое слово assert существует в java. Однако я не помню, как он использует код. Вероятно, я использую исключения и записи в местах, где я мог бы использовать их. Является ли хорошей практикой использовать ключевое слово assert в java?Хорошая практика использования assert в Java?

EDIT: Я знаю, что утверждения в целом - хорошая практика. мой вопрос заключается в том, чтобы быть более точным, если в java BKM утверждения использует ключевое слово assert, а не использует исключение, протоколирование и другие методы.

ответ

18

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

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

Однако хорошим примером, который я видел для использования утверждений, является проверка частных аргументов метода. Поскольку вы контролируете доступ к этим методам, вы можете проверить, что ваш собственный класс правильно использует метод, в то время как ваши общедоступные методы используют более надежные методы проверки аргументов (аннотации, если заявления, сторонние библиотеки и т. Д.). Таким образом, даже если утверждения отключены, ваш метод должен быть защищен, но разработчики, изучающие исходный код, могут увидеть предварительные условия для вашего метода и включить утверждения для дополнительной защиты при работе над этим классом.

+0

«не включен по умолчанию» немного запутанным. Для автономного приложения java вкладчик может включать и выключать его бесплатно. Для управляемых сред (JEE, серверы) он иногда включается по умолчанию - SAP Cloud Platform для интеграции на примере использует Java-утверждения с эффектами Groovy. –

1

Ну, это действительно зависит от того, как вы на это смотрите, но рекомендуется.

Например, если вы написать метод , который вычисляет скорость в частицы, можно утверждать, что расчетная скорость меньше, чем скорости света.

0

Да. Это способ подтвердить, что некоторые условия должны быть выполнены. Обратите внимание, что вы должны явно включать утверждения.

В противном случае вы можете использовать Validate от commons-lang. Вы просто пишете Validate.notNull(foo) и выбрасываете исключение, если foo - null.

2

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

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

Более «современный» подход, например, заключается в использовании Google Guava с Preconditions. Это механизм утверждения типа библиотеки, который вы можете использовать, когда условия должны быть выполнены, и вы не хотите шарить с помощью java-переключателей.

+0

Что касается Guava, то связанное состояние документов: «Исключения предварительного условия [...] используются для оповещения о том, что * вызывающий метод * сделал ошибку. [...] Постусловие или другие инвариантные ошибки не должны бросать эти типы исключений ". который ИМО не делает их заменой для утверждений(), используемых для инвариантов о коде. – pwes

1

Да, это очень хорошая практика для утверждения ваших предположений. Прочитано Design By Contract. assert может использоваться для проверки предварительных условий, инвариантов и пост-условий на этапах интеграции и тестирования. Это помогает уловить ошибки на этапах разработки и тестирования. И вы можете безопасно отключить его во время производства, чтобы избежать проблем с производительностью.

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

1

В моих лекциях algortihms мой преподаватель всегда поддерживал полезность утверждений. theyre в основном используется для тестирования и отладки целей, которые, как я понимаю, вы видите код, используя его. но да, они очень рекомендуются. они могут быть отключены, если вы беспокоитесь о производительности. Обычно я использую System.out.println или контрольные точки для тестирования, но утверждения - это один из способов. вот что я имею в виду:

For example, to prove that sort+reverse is equivalent to sort in reverse order: 
Method 1: sort(int[] arr, int len) 
// pre: len is the length of the array arr 
// post: arr is sorted in ascending order 
Method 2: reverse(int[] arr) 
// post: the order of elements in arr is 
// reversed (e.g. [9 5 10] -> [10 5 9]) 
Assertion 1: the length of arr is len 
sort(arr,len); 
Assertion 2: arr is sorted in ascending order 
reverse(arr); 
Assertion 3: the order of arr is reversed 
0

Это полезно для коротких условий. Однако использование зависит от вашей практики кодирования. Потому что иногда логику можно применять с помощью «assert», используя жесткие методы!

8

Да, это странно. Эта функция была запрошена очень сильно, но после ее ввода в язык ее практически никто не использует.

Я иногда использую assert как инструмент для комментирования. Вместо

// now it should be empty 

Я могу написать

assert size == 0; 

Но я не включил assert, поэтому утверждение никогда не испытанным.

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

7

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

Сказав это, утверждения очень ценны, но многие люди не используют их отчасти потому, что не понимают их. Я слышал, как люди жалуются, что они выбрасывают ошибку вместо исключения. Я также слышал этот вопрос: почему бы вам просто не использовать исключение и не обрабатывать это дело, а не использовать assert?

Мой ответ на оба одинаковых. Утверждения не должны ловить случаи, которые вы ожидаете увидеть в рабочем приложении. Цель утверждений - поймать ошибки. Вы должны использовать их только там, где единственный способ «обработать» их - это вернуться и исправить код. Вот почему они не бросают исключений - вы не хотите, чтобы они были частью вашей общей обработки исключений.

Что касается включения, моя IDE настроена на включение по умолчанию. Итак, для моего внутреннего тестирования я всегда знаю, что они работают.

Вот пример, где утверждение - единственное, что нужно использовать: я работал над большим проектом Swing, где исходные кодеры не понимали, что пользовательский интерфейс может быть обновлен только из потока событий, что привело к разным видам ошибок. Поэтому я вложил это утверждение во множество мест, где дела обстояли смешно: assert EventQueue.isDispatchThread(); Если это утверждение было уволено, мы бежали с неправильной нити, и разработчикам нужно было получить уведомление, чтобы они могли переместить код в нужную нить. Нет никакого способа справиться с этим в рабочем приложении.

1

Я был очень доволен, когда использовал утверждения в своем приложении java, и sqlite-jdbc вернул некоторое разумное утверждение для одного случая.

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

0

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

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

Поэтому я поставил

static { AssertionUtil.enableAssertionsForThisClass(); } 

в верхней части каждого класса. См. http://commons.unkrig.de.

Смежные вопросы