OberonCore

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

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

Очевидно, что решение о том, что есть что, нужно принимать еще при проектировании. И потом жестко проводить это решение в разработке.
Но возможно, что при проектировании принято не совсем правильное решение. Просто в силу отсутствия некоторой информации на момент проектирования. Тогда - что?
Вопрос в том, что возможен ли ГИБКИЙ способ обработки ситуаций.
Как вы эту проблему решаете?

Повторюсь.

1) Ситуации которые являются внешними по отношению к программе (программа не может повлиять на них). Например, ошибка записи на диск.
Такую ситуацию нужно обрабатывать по коду возврата из процедуры. ASSERT в этом случае не нужен.

2) Ситуация которая является внутренней. Например, введена строка, когда ожидалось число.
Такая ситуация должна отлавливаться ASSERTом. Пусть у нас форс-мажор и нам некогда писать корректную проверку типа введённой информации, тогда мы ставим ASSERT который будет гарантировать, что введено число, и предупреждаем пользователей, что вводить нужно только числа. В дальнейшем, когда у нас появится время, этот ASSERT будет нам напоминать, что необходимо дописать проверку на корректность введённых данных, после чего программа перестанет вываливаться, если только не будет иметь место ошибка в реализации проверки или хак со стороны пользователя.

Ну, нет ничего более постоянного, чем временное. ассерт так и будет вечно напоминать, что надо поставить обработку...

может быть. Так было бы, если бы ASSERTа не было, и программа просто падала, а так возможны 2 варианта:
1) пользователи доканают программиста и он таки напишет код;
2) пользователи доканают программиста и он уберёт ASSERT (более вероятно )

Давайте подумаем, в каких местах наиболее уместен ASSERT.
IMHO, это прежде всего проверка предусловий экспортируемых функций.
К (синтаксической) герметичности оберонов ASSERT добавляет (семантический) firewall, препятствующий ошибкам пересекать границы модулей.
"Отлов" большинства других ситуаций, во избежание уродования кода бессмысленными многочисленными проверками, можно поручить компилятору. Например, переполнение числовых типов. А вот предотвращать такие ошибки необходимо на этапе анализа и проектирования, а не кодирования. Вспоминается знаменитая история с падением Ариана-5 из-за переполнения 16-битного целого.
Если есть требование бесперебойной работы системы в режиме 365x24, то необходимы дополнительные меры: перехват исключений (Kernel.Try), да и WatchDog (для встроенных систем) не помешает.

И добавлю. Для обеспечения работы 52*7*24 нужно применять model checking - см. книгу Карпова с означенным названием на озоне.
model checking специально разработан для верификации систем реального времени.

Однако, тут существуют действительно серьезные проблемы:
1. Кто поручится, что сформулированы для проверки действительно ВСЕ свойства, важные для бесперебойной работы системы?
2. В этом методе проверяется не ПО, а модель. Которая никто не гарантирует, что действительно адекватна (полностью соответствует) проверяемой системе. И, к сожалению, нет инструмента автоматической генерации модели по, скажем, тексту программы. А вот у кое-кого некоторый инструмент подобного рода есть - точнее, программа синтезируется автоматически по модели, и эту же модель можно проверить на соответствие формально специфицированным свойствам. Поскольку это именно та модель, по которой генерируется программа, можно надеяться, что проверяются именно ее свойства.

И, кстати, model checking разработан не специально для систем реального времени, изначально как раз он не позволял проверять такие свойства.

Я сужу по книжке Карпова. Там все примеры - системы реального времени... ВременнЫе логики разработаны.

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