Утверждает, что программисты могут найти ошибки или ситуации, которые никогда не должны происходить. Программа должна нормально выполняться, если все утверждения удаляются. Напоритивный раздел программирования в государствах Прагматического программиста
Всякий раз, когда вы обнаруживаете, что думаете: «Но, конечно, этого никогда не произойдет», добавьте код, чтобы проверить его.
Это очень легко принять этот совет и добавить утверждения для обработки каждого негативного случая. Большинство языков предоставляют удобный способ сделать этот чек в коде отладки, который обычно отключается в развертываниях производства после тестирования. Заявления не предназначены для использования для нормальной проверки (то есть обработка ошибок)
Не используйте утверждения для обычной обработки ошибок
Нулевые проверки – Рассмотрим пример Python, где мы собираемся получить доступ к дикту.
def create_auth_header(oauth):
assert oauth
return {"Authorization": "Bearer " + oauth['access_token']}
Assert здесь не предоставляет ничего дополнительного, что языковые ошибки не предоставляют. TypeError или KeyError (в Python) предоставляет больше информации, чем AssertionError. Очень похоже на попытку поймать, утверждают, что по всему коду отвлекает программиста, который читает код из бизнес -логики.
Проверка пользовательского ввода – Хорошая программа всегда подтверждает ввод пользователя, но это никогда не следует делать с утверждениями. Исключения есть по этой причине. В Python все утверждения могут быть проигнорированы при запуске программы в оптимизированном режиме. Все подтверждения пользователя могут быть случайно обойти другой разработчик.
Когда тогда я использую утверждения?
Использование утверждает в качестве инструмента, чтобы предупредить вас, когда вы думаете, что причина и следствие разделены большим количеством кода. Вы когда -нибудь находились в ситуации, когда ошибка в одном куске кода проявляется как странное поведение в совершенно другом модуле, делая отладь кошмара? Мы все были там. Мы стараемся не быть в этой ситуации, задавая много вопросов «что если», когда мы пишем код. Что, если вход нулевой? Что если ключ, который я ищу, недоступен? Что если мир закончился? Если расстояние между причиной, т. Е. Вход, нулевой, и эффект, т. Е. Система, с типамиррором, не находится в пределах функции, метода или самого класса, существует необходимость в утверждении.
Давайте посмотрим на пример, где Assert может сэкономить нам много времени. Этот пример взят из Python Wiki. Пожалуйста, проверьте другие примеры. Они очень полезны в понимании утверждений.
class PrintQueueList:
...
def add(self, new_queue):
assert new_queue not in self._list, \
"%r is already in %r" % (self, new_queue)
assert isinstance(new_queue, PrintQueue), \
"%r is not a print queue" % new_queue
Здесь Assert используется для проверки дубликатов в списке. В этом случае хорошо потерпеть неудачу в этом случае и хорошо спать по ночам, зная, что в этом списке не может быть никаких дубликатов, особенно эффект дубликата может быть только заметным в дальнейшем по пути выполнения, и симптомы могут не указывать напрямую на основную причину Анкет
В итоге,
- Не используйте утверждения, чтобы проверить входные данные, если язык может быстро потерпеть неудачу для вас
- Не используйте утверждения для проверки ввода пользователя
- Не выключайте утверждения в производстве
- Использование утверждает экономно, когда расстояние между причиной и следствием не является непосредственным и, следовательно, уменьшая побочные эффекты
- Используйте утверждения, чтобы предотвратить попадание вашей системы в противоречивое или неэффективное состояние из-за ошибок программиста. Утверждения отлично подходят для выполнения (то есть ошибки внешней причины). «Мы не проверяли этот случай, потому что никогда не думали, что можем попасть сюда», то есть вещи, которые «никогда не должны происходить»
Оригинал: “https://dev.to/yloganathan/do-not-abuse-the-assert-1cfm”