Здравствуйте, Андрей Коростелев, Вы писали:

АК>Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>>Как уже было сказано выше, это насильно создает новые состояния. В клинических случаях они сливаются в одно — в корневом try/catch:

АК>Если введение нового ошибочного состояния не вписывается в текущий контекст — ошибка просто прокидывается выше по стеку вызовов, покуда не встретится контекст, знающий что с ошибкой делать. Причем, при использовании исключений для этого как правило даже не придется писать дополнительный код.

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

АК>Вообще, в такого рода обсуждениях не может быть универсального правильного совета, пока не ясно, что представляет собой f().

Речь не об универсально-правильном совете...

АК>Очевидно, что подход к проверке предуловий будет различен, в случае, если f() является частью loosely-coupled интерфейса для конечного пользователя, и в случае, если f() предназначена для взаимодействоя в рамках high-cohesive системы.

Какой может быть подход в проверке предусловий? предусловия не нужно проверять. В этом смысл DbC. Они _всегда_ выполняются. Иначе теряется их смысл...
Если есть контракт(и не важно в чем он выражен, в документации, в ограничении на типы или другими путями), то он должен соблюдаться. Контекст использования в данном случае не имеет значения. При этом данные(аргументы, etc.) будут проверены явно при первой возможности.