Не злоупотребляйте утверждением

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

Всякий раз, когда вы ловите себя на мысли «но, конечно, этого никогда не может быть», добавьте код, чтобы проверить это.

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

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

def create_auth_header(oauth):
    assert oauth
    return {"Authorization": "Bearer " + oauth['access_token']}

Assert здесь не предоставляет ничего дополнительного, кроме языковых ошибок. TypeError или KeyError (в python) предоставляют больше информации, чем AssertionError. Очень похоже на try and catch , утверждения, разбросанные по всему коду, отвлекают программиста, читающего код, от бизнес-логики.

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

Когда я тогда использую утверждения?
Используйте утверждения как инструмент, чтобы предупредить вас, когда вы думаете, что причина и следствие разделены большим количеством кода. Вы когда-нибудь сталкивались с ситуацией, когда ошибка в одном фрагменте кода проявлялась странным поведением в совершенно другом модуле, превращая отладку в кошмар? Мы все были там. Мы пытаемся избежать такой ситуации, задавая много вопросов «что, если», когда мы пишем код. Что делать, если ввод равен нулю? Что делать, если ключ, который я ищу, недоступен? Что, если бы настал конец света? Если расстояние между причиной, т. е. входными данными, равно null, и следствием, т. е. выходом системы с ошибкой TypeError, не находится внутри самой функции, метода или класса, необходимо утверждение.

Давайте рассмотрим пример, где assert может сэкономить нам много времени. Этот пример взят из Вики Python . Пожалуйста, проверьте и другие примеры. Они очень помогают в понимании утверждений.

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 используется для проверки дубликатов в списке. В этом случае хорошо быстро потерпеть неудачу и спокойно спать по ночам, зная, что в этом списке не может быть никаких дубликатов, особенно эффект дубликата может быть заметен только дальше по пути выполнения, и симптомы могут не указывать напрямую на основную причину. .

В итоге,

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