Java - программирование с утверждениями вопросы

Question

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

Но я никогда не видел ни одного проекта с использованием утверждений (кроме тестов junit/testng ...).

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

Если вы создаете приложение с компонентами, я задаюсь вопросом, куда вы помещаете утверждения: - Со стороны компонента, перед возвратом данных через public api? - На стороне клиента компонента? И если api называется повсюду, вы настраиваете шаблон фасада, который будет вызывать механизм утверждения? (Тогда я предполагаю, что вы положили свои утверждения и фасад на какой-то внешний проект, и ваши клиентские проекты будут зависеть от этого проекта утверждения?)

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

Благодаря

Answer 1

Btw, вы обратитесь к assert в Java?

Я лично нахожу утверждения, особенно полезные для инвариантов. Учтите, что проверка утверждений по умолчанию отключена в java. Вы должны добавить флаг -ea, чтобы включить проверку утверждений. Другими словами, вы можете протестировать свое приложение в каком-то режиме отладки, когда программа будет остановлена, как только будет нарушено утверждение. С другой стороны, в заявлении о выпуске будет отключено его утверждение и не будет требовать штраф за проверку достоверности, они будут проигнорированы.

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

Моя грубая политика, особенно при работе со многими разработчиками:

• публичных методами: всегда проверять аргументы и бросить IllegalArgumentException когда что-то не так
• частных метод: использование утверждений, чтобы проверить аргументы против нулевых указателей и так на
• комплексных методов: промежуточные утверждения, чтобы гарантировать, что промежуточные результаты удовлетворяют требуемые свойства

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

Answer 2

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

О расширении Error Я предполагаю, что он расширяет ошибку, поскольку ошибки являются исключениями, которые не ожидаются. И таким образом, когда в вашем коде у вас есть catch (Exception), утверждение не кэшируется.

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

Answer 3

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

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

Чтобы отключить утверждения:

-da flag in compiler

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

Answer 4

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

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