abap - ABAP 中的断言

Question

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

但是，这一切似乎不适用于为 SAP 编写 ABAP 代码。我刚刚花了一个小时的大部分时间试图找出断言给我带来难以理解的错误的精确位置。事实证明，这在标准 SAP 代码中低了五个级别，显然充斥着 ASSERT 语句。我现在知道标识表的某个变量不是初始的，而标识字段的伴随变量则是初始的。

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

因此，我的问题是在 ABAP 中使用断言的指南或最佳实践是什么。 SAP 写的代码很糟糕吗？用断言填充自定义代码并在交付代码时将它们保留在其中是否是一种可接受的做法？如果是这样，我们将如何在运行时处理这些断言，以便应用程序不会崩溃，同时仍然能够识别错误原因？

Answer 1

ABAP 开发中的指南和最佳实践实际上与任何其他语言中的指南和最佳实践相同。断言应仅用作内部指导检查，常规输入验证错误和其他内容的异常(exception)情况。将断言留在代码中可能是明智的 - 毕竟，您可能宁愿希望程序以受控方式崩溃，也不愿以不可预见的方式继续，并且可能会在没有人注意到的情况下损坏过程中的一些关键数据。看看checkpoint groups如果您不希望您的程序在生产环境中中止 - 但在我看来:如果在最重要的环境中禁用健全性检查(作为最后一道防线)，那么它有什么用？

当然，我假设输入已正确验证(以便防止崩溃)，并且所有 API 均根据预期用途和文档使用。不幸的是，与所有其他编程语言一样，开发人员必须遵守这些标准。