在没有断言的情况下在运行时检查没有内容答案

【问题标题】：check with no content at runtime without assertions在没有断言的情况下在运行时检查没有内容
【发布时间】：2019-12-03 23:24:00
【问题描述】：

据我在 Eiffel 中的理解，如果语句返回 False，则以下不带断言的代码将失败

check
    i_m_alive: i.alive
then
    do_nothing
end

也许我用得不好，但有时我想检查它而不做任何其他事情。

这个语句有和没有断言的确切行为是什么？
我应该使用raise 和if 语句吗？
我有时会尝试向check ... then 添加一个else 语句，但我确定它没有实现是有原因的，可能是因为没有替代方案，因为如果语句返回True，则会引发异常

特别是在 EWF（Eiffel Web 框架）上，我看到报告错误并处理它的唯一方法是写入日志或将详细信息发送给引荐来源网址，其中包含一些有时不足以发送给用户的详细信息。向管理员发送电子邮件也是一种可能......我有点迷茫，但知道 raise 和 Exception 机制不是 Eiffel 建议的处理错误的方式。

我将进一步深入了解available documentation 的相关内容，但作为我的 TL；DR 将很乐意对此有更简洁的答案或更多观点。

【问题讨论】：

我建议将关于rescue 和堆栈跟踪的最后一个问题移至另一篇帖子，因为它与原始问题没有直接关系，并且违反了只问一个问题而不是多个问题的规则。
@AlexanderKogtenkov Thx，实际上我发现了你写的更多信息，并认为我混合了太多东西，无法在正确的情况下做正确的事情。我认为我的软件必须按照您在以下链接中的建议使用更多的错误控制，而不是检查、重试、引发。 stackoverflow.com/questions/26956743/…
我会更深入地研究我的代码，一旦我的头脑清楚，使用异常的坏习惯和在埃菲尔似乎仍未修复的错误中，我会提出更多问题编译器不能让我用断言编译最终可执行文件以进行测试和生产让我感到困惑

标签： eiffel

【解决方案1】：

将断言视为在代码中指定程序当前状态的语句。例如：

这里的变量x等于5；
这里列表的所有元素都附加到现有对象；
这里两个结构有如下关系，等等

断言只是描述程序的行为（即它们是声明性的）。它们没有定义行为（即它们不是强制性的）。

断言可以有不同的形式：类不变量、前置条件和后置条件、循环变体等。但它们都是在运行时执行到相应点时程序状态的声明。删除此类声明不会改变行为。是否检查断言由编译器和运行时选项控制。如果程序是正确的，即没有任何一个断言被违反，这样的删除不会影响最终结果（可能除了性能）。此外，一些工具可以在编译时验证断言，因此根本不需要运行时检查。换句话说，断言用于指定程序行为，而其他代码用于实现该行为。

但是，如果程序不正确，则会触发异常。它告诉程序员有一个错误，应该修复它。

这同样适用于构造 check ... then ... end。它表示始终满足指定条件（如果实现正确）。如果违反条件，则程序中存在错误。这就是为什么没有else 部分的原因：这个结构不控制程序执行，它只是检查执行是否按预期进行。

如果编译器足够聪明，if 可以在编译时检查条件并报告错误，或者完全删除条件（如果可证明从未违反）。但是，目前的技术还不存在。结果，检查条件的代码（我们称之为“假设”）在运行时生成并检查。特别是，它确保then 部分中的代码可以安全地依赖于检查假设。当编译器无法正确推断（作为开发人员为您）已知的表达式的附加状态时，此类检查在void-safe 代码中变得至关重要。与其他断言不同，此断言不能关闭（事实上，SCOOP 中的某些前提条件也不能关闭 - 它们是语义的一部分）。

如果您想使用异常作为控制程序行为的一种方式，那么断言不是正确的工具。正如您所提到的，应改为使用对 raise 异常的显式调用。

总结一下：

断言描述程序行为，它们并不打算影响该行为；
应明确提出控制程序行为的异常（应避免这种情况）；
check ... then ... end 是强制性的，无论编译器和运行时设置如何，都会对其进行检查；
没有else 部分，因为断言不控制程序行为。

【讨论】：