ABAP中的断言

Question

多年来,我已经用各种语言和环境编写代码,但是一个常数似乎是关于断言使用的共识.据我所知,当你想要识别"不可能"的错误以及你的第一反应是"无法正确"并且无法正常处理的其他情况时,它们就在那里用于开发过程,使系统保持原状一个国家,它别无选择,只能终止.断言易于理解且编码速度快,但由于其快速失败性质不适合开发代码.理想情况下,断言用于发现所有开发错误,然后在发送代码时删除或关闭.输入或编程状态错误,

但是,对于编写SAP的ABAP代码而言,这似乎都不适用.我花了大约一小时的时间试图追踪断言给我一个难以理解的错误的确切位置.事实证明,标准的SAP代码中有五个级别,这显然充满了ASSERT陈述.我现在知道标识一个表的某个变量,IS NOT INITIAL而它的伴随变量标识一个字段.

这没告诉我什么.运行此代码的Web Dynpro组件实际上"捕获"此断言,向我显示一条通用错误消息,该消息仅用于防止调试器在断言时启动.

因此,我的问题是在ABAP中使用断言的准则或最佳实践.这个SAP写错了代码吗？使用断言填充自定义代码并在发送代码时将它们保留在一起是否是公认的做法？如果是这样,我们将如何在运行时处理这些断言,以便应用程序不会崩溃和刻录,同时仍然能够识别错误的原因？

Answer 1

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

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