据我在Eiffel中了解，如果语句返回False
check
i_m_alive: i.alive
then
do_nothing
end
也许我用得不好，但是有时候我想不做任何其他事情就检查它。
raise语句中使用if吗？check ... then添加else语句，但是我没有实现，我确信是有原因的，可能是因为没有其他选择，因为如果语句返回{{1} } 特别是在EWF（Eiffel Web Framework）上，我看到报告错误并加以处理的唯一方法是写入日志或将详细信息发送给引荐来源网址，其中某些详细信息有时不足以发送给用户。向管理员发送电子邮件也是一种可能性……我有点迷茫，但是知道加薪和异常机制并不是Eiffel建议处理错误的方式。
我将进一步探讨available documentation，但作为我，TL; DR会很乐意对此有一个更简洁的答案或更多观点。
答案 0 :(得分：2)
从声明中考虑断言，这些断言指定代码中程序的当前状态。例如：
此处变量x等于5;
此处列表的所有元素都附加到现有对象上；
这里两个结构具有以下关系，等等。
断言仅描述程序的行为（即，它们是声明性的）。它们没有定义行为（即不是必须的）。
断言可以以不同的形式出现：类不变式，前置条件和后置条件，循环变体等。但是，当执行在运行时到达相应点时，它们全都是程序状态的声明。删除此类声明不会更改行为。声明是否被检查由编译器和运行时选项控制。如果程序正确，即没有违反任何一个断言，则此类删除不会影响最终结果（可能会影响性能）。此外，某些工具可以在编译时验证断言，因此根本不需要运行时检查。换句话说，断言用于指定程序行为，而其他代码用于实现行为。
但是，如果程序不正确，则会触发异常。它告诉程序员有错误，应该纠正。
构造check ... then ... end也是如此。它说始终满足指定的条件（如果实现正确）。如果违反条件，则程序中存在错误。这就是为什么没有else部分的原因：此结构不控制程序的执行，它只是检查执行是否按预期进行。
如果编译器足够聪明，则可以在编译时检查条件并报告错误，或完全删除条件（如果证明从未违反）。但是，当前的技术还不存在。结果，将在运行时生成并检查条件的代码（我们称其为“假设”）。特别是，它可以确保then部分中的代码可以安全地依赖于检查的假设。当编译器无法正确推断（作为开发人员）已知始终附加的表达式的附加状态时，此类检查在void-safe代码中变得至关重要。与其他断言不同，该断言无法关闭（实际上，SCOOP中的某些前提条件也无法关闭-它们是语义的一部分）。
如果要使用异常作为控制程序行为的方式，则断言不是正确的工具。如您所述，应该使用对raise异常的显式调用。
总结：
断言描述了程序的行为，并非旨在影响程序的行为；
应明确提出控制程序行为的例外情况（应避免这种情况）；
check ... then ... end是强制性的，并且无论编译器和运行时设置如何，都将对其进行检查；
没有else部分，因为断言不控制程序行为。