问题描述
使用指南支持库和实用程序，如 gsl_Expects C++ 暂时实现了契约（有计划在未来将这些东西融入到语言中）。使用此功能并根据您的项目设置，可能会违反合同：
- 抛出异常或
- 呼叫终止
我想知道恢复策略应该是什么。很明显，在第二种情况下（您设置合同违规以调用终止），没有，但即使在第一种情况下也很难恢复；由于异常属于某种内部类型（例如，从 fail_fast 派生的 logic_error），因此很难构建恢复策略：我应该捕获什么异常，在哪个级别，是否有有用的信息将帮助我恢复（我认为 file+line 是为了让人类读者进行事后分析）。
考虑到所有这些，我的问题是：您打算从违反合同的情况中恢复过来吗？如果是，怎么做？ 是否有描述如何做的来源？如果不是，将我的错误检查+处理与合同检查分开并仅从硬错误的角度考虑合同是否是个好主意？
我想我倾向于第二种选择，但令人讨厌的是，这些违规行为会导致我的整个程序崩溃，而不是使单个函数无效。
我可以像这样构建合约承载功能：
std::optional<return_t> my_function(Arg arg)
{
std::optional<return_t> ret;
try {
gsl_Expects(...); // do contract checking
/* rest of function */
} catch (fail_fast& e) {
// report contract violation
}
return ret; // Exceptions from contract violations are turned into empty optional
// Other exceptions are handled like before (locally or from the caller)
}
但感觉它违背了使用合约的目的。
解决方法
您不打算从合同错误中恢复过来。合同错误是程序中的逻辑错误，换句话说，您的程序是错误的。没有任何可行的方法可以从中恢复，您能做的最好的事情就是杀死并重新启动发生故障的整个子系统，并希望这是一次罕见的故障。
您可以预期的异常情况不应该由合约处理，这就是异常机制的用途。
,可能有一些策略。
假设一个程序显示了一些 UI，用户打开了一些文件，并且由于该文件已损坏，加载数据违反了一些合同。
异常处理不会在恢复文件结构的一致状态方面做一些“恢复”，而只会破坏文件关联的结构，并报告错误。
这仍然不是“硬”错误。 UI 相关结构完好无损，程序可以继续。
当然，这可能被认为不是很好的做法。理想情况下，所有外部数据都经过验证，因此不良数据不会违反合同，因此违反合同是致命的。不确定您是否正在编写理想的程序。我没有。