在很多老派 ABAP 系统里，MESSAGE像空气一样无处不在：校验失败就MESSAGE e...，权限不足就MESSAGE a...，用户提示也MESSAGE s...。这套机制在经典dynpro的PAI里确实顺手，能立刻把错误弹回界面，引导用户修正输入；可一旦你把同样的代码搬到应用层、后台作业、RFC、OData，甚至RAP的行为实现里，事情就会变得非常微妙：同一条MESSAGE，在不同上下文里可能是对话框、状态栏、终止事务，甚至直接短 dump。SAP 自己也明确指出：不带RAISING或INTO的消息，本质是面向用户交互的，除了类型X等极端情况外，MESSAGE不应出现在应用逻辑层。(SAP Help Portal)
问题在于，现实项目没法一刀切。你总会遇到这种场景：新代码全面采用类异常（CX_ROOT家族），但仍要调用一堆遗留过程（函数、子程序、老类方法），它们抛的是“基于消息的经典异常”：要