企业级系统里,异常 往往不是为了制造 dump,而是为了把系统运行过程中必然会遇到的不确定性,用一种可读、可控、可测试的方式表达出来。尤其在 ABAP 这种强调接口契约、强调跨团队协作的生态里,异常设计做得好不好,直接决定了接口调用方会不会被惊吓,也决定了你的服务在 OData、RAP、批处理等不同消费方式下,能不能给出一致、可理解的错误反馈。
这篇文章聚焦一个非常实用、也非常容易被忽视的原则:如果某类错误是可以预期的,并且接收方能够合理处理,就应该抛出继承自 CX_STATIC_CHECK 的受检异常,把它写进方法签名,强制调用方做出响应。 这一点在 SAP 官方对异常类别的说明中也有明确导向:CX_STATIC_CHECK 的价值在于强制直接调用者处理或显式转发,让异常成为接口的一部分。 (SAP Help Portal)
为什么要把异常当成接口契约
很多团队在 ABAP 项目里习惯两种做法:
- 用
sy-subrc
订阅专栏 解锁全文
3552

被折叠的 条评论
为什么被折叠?



