Если assert не удается, есть ли ошибка?

Question

Я всегда следовал логике: если assert терпит неудачу, то есть ошибка. Основной причиной может быть:

• Утверждение само по себе неверно (ошибка)
• Ошибка программирования (ошибка)
• (других вариантов нет)

т.е. Есть ли другие выводы, к которым можно прийти? Существуют ли случаи, когда утверждение не будет выполнено и ошибки нет?

Answer 1

Если assert терпит неудачу, есть ошибка в вызывающей или вызывающей стороне. Почему еще было бы утверждение?

Answer 2

Да, в коде есть ошибка.

Код завершен

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

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

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

Answer 3

Хороший вопрос.

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

Answer 4

Только если assert должен был показать условие предупреждения - в этом случае должен был использоваться специальный класс assert.

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

Answer 5

Если вы используете утверждения, вы следуете Дизайн Бертрана Мейера по контракту философия. Это ошибка программирования - указанный вами контракт (утверждение) не выполняется клиентом (вызывающей стороной).

Answer 6

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

Это может означать:

• Ошибка в вашем коде (вы просто неправильно вызываете метод)

• Ошибка в утверждении (первоначальный программист был слишком ревностным и жалуется на то, что вы делаете что-то вполне разумное, и метод на самом деле отлично справится.

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

• Известная, но не реализованная функция. Представьте, что я реализую метод, который может обрабатывать положительные и отрицательные целые числа, но он мне нужен (пока) для обработки положительных. Я знаю, что «идеальная» реализация будет справляться с обоими, но пока мне на самом деле не понадобится ее для обработки негативов, это пустая трата усилий для реализации поддержки (и это добавит раздувание кода и, возможно, замедлит мое приложение ). Поэтому я рассмотрел этот случай, но я решил не реализовывать его, пока необходимость не будет доказана. Поэтому я добавляю утверждение, чтобы пометить этот не реализованный код. Когда я позже запускаю утверждение, передавая отрицательное значение, я знаю, что теперь необходимы дополнительные функции, поэтому я должен расширить реализацию. Откладывание написания кода до тех пор, пока оно действительно не требуется, таким образом, экономит мне много времени (в большинстве случаев я никогда не реализую функцию дополнения), но утверждение гарантирует, что я не получаю никаких ошибок, когда пытаюсь использовать невыполненную функцию.

Answer 7

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

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

Пример из реальной жизни (хотя и до эпохи утверждений): если определенный каталог был скрыт наопределенная машина программа будет barf.Я никогда не нашел ни одного куска кода, который должен был бы заботиться, если каталог был скрыт.У меня был только очень ограниченный доступ к машине-нарушителю (на ней была куча бухгалтерских материалов), поэтому я не мог правильно на ней охотиться и не мог воспроизвести ее в другом месте.Что-то, что было сделано с этой машиной (виновник так и не был идентифицирован) иногда превращало этот каталог в скрытый.

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

Answer 8

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

Вероятность исчезающе мала, но все же не равна нулю.