ABAP中的断言

多年来，我用各种语言和环境编写了代码，但其中一个不变的因素似乎是关于断言使用的共识。据我所知，当您想要识别“不可能”的错误和其他情况时，它们会出现在开发过程中，您的第一反应是“不可能是正确的”，并且无法优雅地处理，从而使系统处于一种除了终止之外别无选择的状态。断言很容易理解和快速编写代码，但由于其快速失败的特性，不适合开发代码。理想情况下，断言用于发现所有开发错误，然后在发布代码时删除或关闭。输入或程序状态是错误的，但可能（并且预期会发生）应该通过异常或其他错误处理技术进行优雅的处理

然而，在为SAP编写ABAP代码时，这一切似乎都不成立。我刚刚花了大半个小时试图找到断言给我一个无法理解的错误的确切位置。结果证明，标准SAP代码的级别降低了五个级别，这显然充满了

ASSERT

语句。我现在知道，标识表

的某个变量不是INITIAL

，而标识字段的伴随变量是INITIAL

这跟我没什么关系。运行此代码的Web Dynpro组件实际上“捕获”了此断言，并向我显示了一条通用错误消息，该消息仅用于防止调试程序在断言被触发时启动

---

因此，我的问题是在ABAP中使用断言的指导原则或最佳实践是什么。这是SAP编写的错误代码吗？在您的自定义代码中填入断言，并在发送代码时将其留在代码中，这是一种公认的做法吗？如果是这样，我们将如何在运行时处理这些断言，以便应用程序不会崩溃和烧坏，同时仍然能够确定错误的原因？

ABAP开发中的指导原则和最佳实践与任何其他语言中的指导原则和最佳实践基本相同。断言应仅用作内部指导检查、常规输入验证错误和其他内容的例外。将断言留在代码中可能是明智的——毕竟，您可能更希望您的程序以可控的方式崩溃，而不是以不可预见的方式继续，并可能在没有人注意的情况下损坏过程中的一些关键数据。看看您是否不希望您的程序在生产环境中中止—但在我看来：如果在最重要的环境中禁用了健全性检查（作为最后一道防线），它有什么用

---

当然，我假设输入已正确验证（以防止崩溃），并且所有API都是根据预期用途和文档使用的。不幸的是，与其他任何编程语言一样，要达到这些标准取决于开发人员

关于assert的使用，我真的没有答案（我只在dev中使用它来强制测试错误条件），但我可以告诉您，SAP总是写错误代码。如果他们这样做，我一点也不会感到惊讶。我支持这一观点。除非您碰巧是第一个遇到这种错误情况的人，否则在SAP notes中搜索断言是找到问题解决方案的快速方法。比以后尝试修复损坏的数据容易得多。