多年来，我用各种语言和环境编写代码，但有一个不变的似乎是关于使用断言的共识。据我了解，当您想要识别"不可能"的错误和其他情况时，它们就在那里，您的第一反应是"不可能正确"并且无法优雅地处理，使系统处于别无选择的状态，只能终止。断言易于理解且编码快速，但由于其快速失败的性质不适合开发代码。理想情况下，断言用于发现所有开发错误，然后在交付代码时删除或关闭。错误但可能（并且预期会发生）的输入或程序状态应通过异常或其他错误处理技术进行优雅处理。
但是，对于为 SAP 编写 ABAP 代码，这些似乎都站不住脚。我刚刚花了大半个小时试图追踪断言给我一个难以理解的错误给出的确切位置。事实证明，这在标准SAP代码中降低了五个级别，显然充斥着ASSERT语句。我现在知道标识表的某个变量IS NOT INITIAL而标识字段的伴随变量是。
这什么也没告诉我。运行此代码的 Web Dynpro 组件实际上"捕获"了此断言，向我显示了一个通用错误消息，该消息仅用于防止调试器在断言跳闸时启动。
因此，我的问题是，在ABAP中使用断言的准则或最佳实践是什么。这是SAP在写糟糕的代码吗？使用断言填充自定义代码并在交付代码时保留它们是否是一种公认的做法？如果是这样，我们将如何在运行时处理这些断言，以便应用程序不会崩溃和烧毁，同时仍然能够确定错误的原因？
与任何其他语言中的指南和最佳实践几乎相同。断言应仅用作内部指导检查、常规输入验证错误和其他内容的例外情况。将断言保留在代码中可能是明智的 - 毕竟，您可能宁愿希望程序以受控方式崩溃，而不是以不可预见的方式继续运行，并且可能会在此过程中损坏一些关键数据而没有人注意到。如果您不希望程序在生产环境中中止，请查看检查点组 - 但在我看来：如果在最重要的环境中禁用健全性检查（作为最后一道防线），它有什么用？
当然，我假设输入已正确验证（以防止崩溃），并且所有API都根据预期用途和文档使用。不幸的是 - 与所有其他编程语言一样 - 开发人员需要达到这些标准。