2

我非常喜欢在我的代码中测试不变量和前置条件的断言行为。我经常使用它。但是现在我正在开发一个库（C++），我喜欢客户端（使用库的程序员）知道他什么时候违反了先决条件。我认为看到应用程序崩溃并解决问题比仅仅抛出未定义的行为更容易。

在这种情况下我可以只使用断言，但是当我的库准备就绪时，发布版本将禁用断言宏。我知道我可以保留它，但我不确定我是否愿意，因为有很多内部断言不需要在发布版本中进行测试。

一个实例：某些状态机具有可以添加的最大状态数。限制由客户端在构造函数中设置。然后，客户端调用方法 addState 来添加特定的状态，但是当然，他不能添加比他最初说的更多的状态。

我是不是该：

  1. 只是忽略限制后的状态，并且可能启动具有未定义行为的状态机（至少从客户端的角度来看）？
  2. 让断言保持活力并在那个时候提出断言？
  3. 抛出异常（我猜是一些 std::logic_error）？
  4. 只需向 stderr 打印一条消息并中止程序？

我不喜欢 1. 非常。这个想法是告诉客户他做错了什么。

这是引发逻辑错误异常的情况吗？还有另一种更好的可能性吗？

谢谢。

4

1 回答 1

1

当然，如果一个问题是“可检测的”，你应该做一些事情来通知“用户”这个错误（有些事情很难确定它出错了）

当程序员直接出错时使用断言，而这在代码的“正常使用”中不太可能发生。例如，如果您有一个不能为 NULL 的指针参数，那么做assert(ptr != NULL)将是一件明智的事情，同样，如果您有一个int可以计数的东西，它可能不应该是负数（但它可能应该是unsigned？）。这些类型的事情不一定需要清楚地记录 - 只是前提条件“ptr不能为 NULL”或“count不应该为负数”。

您对在正常运行条件下可能发生但实际上不应该发生的事情使用异常。例如内存不足，或者“用户”试图向他们有理由首先给出合理大小的东西添加太多东西。异常应该通过函数的描述清楚地记录——“如果你尝试添加比你保留空间更多的状态，异常 x 将被抛出”。

我个人认为“自定义”异常比std::logic_error. 在这种情况下，也许too_many_states？您的异常越明显，就越容易确定它的来源和含义。没有什么比得到一些“通用”异常并且不知道你是如何到达那里更糟糕的了——当你搜索它时，它可能来自数百个地方......

于 2013-07-03T08:01:50.653 回答