Я всегда следовал за логикой: если утверждают сбои, то существует ошибка. Первопричина могла или быть:
Т.Е. Есть ли какие-либо другие заключения, в которые можно было приехать? Есть ли случаи, где утверждение перестало бы работать и нет никакой ошибки?
Да, в коде есть ошибка.
Утверждения проверяют наличие условий, которые никогда не должно происходить. [...]
Если утверждение сделано за аномальный состояние, корректирующее действие не просто для обработки ошибки изящно - корректирующее действие изменить исходный код программы, перекомпилировать и выпустить новую версию программного обеспечения.
Хороший способ думать об утверждениях как об исполняемых документация - на них нельзя положиться заставить код работать, но они могут более активно документировать предположения чем комментарии на языке программ.
Это хороший вопрос.
Мне кажется, что если assert не срабатывает из-за вашего кода, то это ошибка. Утверждение - это ожидаемое поведение/результат вашего кода, поэтому сбой утверждения будет ошибкой вашего кода.
Если вы используете утверждения, вы следуете философии Бертрана Мейера "Дизайн по контракту" . Это программная ошибка - указанный вами контракт (утверждение) не выполняется клиентом (вызывающим).
Только если утверждение должно было показать состояние предупреждения - в этом случае следовало бы использовать специальный класс утверждений.
Таким образом, любой assert должен показать ошибку, как вы предлагаете.
Если вы пытаетесь логически раскрыть все возможности, помните, что электронные схемы, как известно, подвержены влиянию космического излучения. Если нужный фотон / частица попадает в нужное место в нужное время, это может вызвать в противном случае логически невозможный переход состояния.
Вероятность исчезающе мала, но все же отлична от нуля.
Я могу вспомнить один случай, который на самом деле не классифицируется как ошибка:
Утверждение, размещенное для проверки чего-то внешнего, что обычно должно быть там. Вы охотитесь за чем-то ненормальным, что происходит на одной машине, и хотите знать, ответственен ли за это определенный фактор.
Пример из реального мира (хотя и до эпохи ассертов): Если определенная директория была скрыта на определенной машине, то программу тошнило. Я так и не нашел ни одного фрагмента кода, которому было бы не все равно, скрыт ли каталог. У меня был очень ограниченный доступ к машине-нарушителю (на ней была куча бухгалтерских вещей), поэтому я не мог как следует поохотиться на нее и не мог воспроизвести это в другом месте. Что-то, что было сделано с этой машиной (виновник так и не был определен), периодически делало этот каталог скрытым.
В конце концов, я прибег к использованию теста при запуске, чтобы проверить, скрыт ли каталог, и остановить его с ошибкой, если он скрыт.
Если assert не работает, есть ошибка либо в вызывающем, либо в вызываемом. Иначе зачем было бы такое утверждение?
Нет. Ошибка утверждения означает, что произошло что-то, чего исходный программист не планировал или не ожидал.
Это может указывать на:
Ошибка в вашем коде (вы просто неправильно вызываете метод)
Ошибка в утверждении (исходный программист был слишком усерден и жалуется на то, что вы делаете что-то довольно неуместное). разумно, и метод на самом деле справится отлично.
Ошибка в вызываемом коде (недостаток дизайна). То есть вызываемый код предоставляет контракт, который не позволяет вам делать то, что вам нужно. Утверждение предупреждает Вы не можете этого сделать, но решение состоит в том, чтобы расширить вызываемый метод для обработки вашего ввода.
Известная, но не реализованная функция.Представьте, что я реализую метод, который может обрабатывать положительные и отрицательные целые числа, но мне он нужен (пока) только для обработки положительных. Я знаю, что «идеальная» реализация справится с обоими, но до тех пор, пока мне действительно не понадобится для обработки негативов, реализация поддержки будет пустой тратой усилий (и это добавит раздувания кода и, возможно, замедлит мое приложение. ). Я рассмотрел этот случай, но решил не реализовывать его, пока необходимость не будет доказана. Поэтому я добавляю утверждение, чтобы отметить этот нереализованный код. Когда я позже инициирую утверждение, передав отрицательное значение, я знаю, что теперь необходимы дополнительные функции, поэтому я должен расширить реализацию. Отсрочка написания кода до тех пор, пока он действительно не понадобится, тем самым экономит мне много времени (в большинстве случаев я никогда не реализую дополнительную функцию), но assert гарантирует, что я не получу никаких ошибок, когда я попытаюсь использовать нереализованную функцию.