如何处理无效的执行状态？

Question

假设您有以下代码块：

if (Light.On) {
    // do something...
} else if (Light.Off) {
    // do something else...
} else {
    // this state should never be reached
}

现在假设应用程序逻辑指示在这部分代码中，永远不应达到最后状态，但这不是可以在编译时确定的东西。 也许还有其他状态（例如 Light.Broken）可以由应用程序的其他部分设置，但此处未使用。

您在最后一个 else 块中添加了什么代码？

1. 不添加任何代码，因为无论如何都不应该到达它。
2. 添加一些日志记录功能，以便作为开发人员的您知道已经达到了某种非法状态。
3. 抛出异常，因为一定不能达到该状态，并且如果无论如何都达到了，则一定有其他问题。

第一个选项对我来说似乎不合理，希望事情进展顺利似乎不是正确的选择。 选项二的优点是您的应用程序不会立即崩溃，因此如果这种情况发生在测试中未发现的极少数情况下，客户可以继续使用该应用程序，并且开发人员会收到有关问题的通知。 选项三会导致应用程序崩溃，这显然不是您希望客户经历的情况，但它确实清楚地表明出了问题。

处理这种情况的最佳方法是什么？

根据评论进行编辑：

引导讨论的一些额外注意事项：

• 包含上述代码的方法的契约不允许在此时设置除 On 和 Off 之外的任何其他值。
• 假设代码位于应用程序的不那么关键的部分。

Answer 1

在开发过程中——努力失败并快速失败。 抛出某种运行时异常，或者只是 Assert(false)。

在发布中 - 优雅地关闭。 您的应用程序处于无法使用的状态，并且您无法真正执行通常会执行的任何操作，例如类不变量等。给用户一个保存其工作的机会，例如，尝试并记录一个可能会发送回的错误开发团队然后关闭。

编辑：根据添加的评论。

如果函数的契约规定灯应该在函数入口处打开或关闭，那么任何其他状态都是错误的。 根据我原来的答案中概述的原则，该功能应该失败。

关于“非关键”方面 - 如果不满足功能前提条件，则意味着您的应用程序已损坏。 无论是否在非关键代码段中检测到错误，这并不意味着问题本身是非关键的 - 您无法知道创建无效状态的错误是否也会影响代码的关键区域。

Answer 2

这得看情况。 进行布尔测试的第三个案例会让我想哭。 这只是噪音，增加了混乱，并告诉我开发人员至少和我感觉的一样困惑。

对于非布尔值，我想你可以做任何事情......如果 if 捕获与相关代码相关的状态，那么忽略其他情况并没有什么坏处。 如果将来很可能需要更多案例，为了清楚起见，评论可能足以表明这一点。

Answer 3

正如已经说过的，在开发阶段你应该尽快让它可见。 在发布阶段，这取决于达到这种无效状态的关键程度。

至少是出于调试目的发出日志。

然后，您可以尝试通过返回到先前的有效状态或进入新的有效状态来从此无效状态恢复。

最后，如果无法采取任何安全措施，您可以终止执行（向用户发出警报并向维护者发送日志）。

Answer 4

第三个选项是正确的，就好像该部分的任何其他状态都无效一样，因此它应该抛出异常并指出无效状态。

Answer 5

什么都不要做。 如果您只关心灯是否亮起：

if (Light.On) {
    // do some work
} else {
    // too darned dark to work
}

否则您应该枚举所有状态。

如果其他状态不允许，则应该出错。 如果允许但不相关，请忽略它们。 只要代码设计得当，就没有问题。

这里的主要问题在于可以同时设置 Light.On 和 Light.Off 的设计。 您应该使用状态 Light.State，将其设置为 {on、flickering、off、broken、unplugged、exploded、emitting_dangerous_gamma_rays} 等之一。

Answer 6

抛出异常。

正如你所说，第三种情况绝对不应该发生。 如果确实发生了，那么就会出现问题，而且您不知道还会出现什么问题。

您也不希望调用代码时认为代码正常工作，而实际上它却失败了。

此外，它使得在问题发布之前更容易发现问题。

Answer 7

在开发版本中，抛出异常即可。

在发布版本中：

• 抛出异常
• 如果可能，将用户的工作保存在某个临时文件中
• 保存故障转储并（使用小型帮助应用程序）为用户提供将其发送给您的选项，以便您可以识别并修复问题