我非常喜欢在我的代码中测试不变量和前置条件的断言行为。我经常使用它。但现在我正在开发一个库（C ++），我喜欢客户端（使用该库的程序员）知道他何时违反了前提条件。我认为更容易看到应用程序崩溃并修复问题，而不仅仅是抛出一个未定义的行为。
我可以在这种情况下使用assert，但是当我的库准备就绪时，发布版本将禁用断言宏。我知道我可以保留它，但我不确定我想要，因为有很多内部断言不需要在发布版本中进行测试。
一个实例： 某些状态机具有可添加的最大状态数。限制由构造函数中的客户端设置。然后，客户端调用方法addState来添加特定的状态，但当然，他不能添加比他最初说的更多的状态。
我应该：
我不太喜欢1.这个想法告诉客户他做错了什么。
这是抛出逻辑错误异常的情况吗？ 还有另一个更好的可能性吗？
感谢。
答案 0 :(得分：1)
当然，如果问题是＆＃34;可检测到＆＃34;，你应该做一些事情来通知＆＃34;用户＆＃34;错误（有些事情很难确定它出错了）
当程序员做了一些直接错误的事情时你使用断言，并且这不太可能发生在＆＃34;正常使用＆＃34;的代码。例如。如果你有一个不能为NULL的指针参数，那么做assert(ptr != NULL)将是一个明智的事情，同样如果你有一个int是一个事物的数量，它可能不应该是＆＃39; t是否定的（但那应该是unsigned？）。这些类型的东西不一定需要明确记录 - 只是前提条件＆＃34; ptr不能是NULL＆＃34;或者＆＃34; count不应该是否定的＆＃34;。
您可以在正常运行条件下使用异常，但实际上不应该这样做。例如耗尽内存，或者用户＆＃34;试图将太多的东西添加到他们有理由首先给出合理尺寸的东西上。异常应该通过函数的描述清楚地记录 - ＆＃34;如果你尝试添加的状态多于你有保留空间的状态，那么异常x将被抛出＆＃34;。
我个人认为＆＃34; custom＆＃34;异常比std::logic_error更有意义。在这种情况下，也许too_many_states？您的异常越明显，就越容易确定它的来源和含义。没有什么比得到一些＆＃34;泛型＆＃34;更糟糕的了。例外，不知道你是如何结束的 - 当你搜索它时，它可能有数百个地方来自......