我使用构造函数表达式的原因恰恰是您提到的原因："乍一看，我看到此COND功能块仅向我返回R_RESULT"-并且避免与所有中间变量混淆。

潜在的 构造表达式的复杂性经常被批评，但这通常是因为开发人员还不习惯与它们合作。 我会毫不犹豫地使用复杂的表达式来避免所有中间变量（并表明目标仅是初始化一个变量）。 如果开发人员不清楚，自动化的单元测试应该有助于理解复杂的构造表达式的功能。 当然，我认为复杂性是一个不应该达到的极限，但我不能告诉我们如何定义它。

PS：也许您的例子并不是说明您问题的最佳例子：我 会保留旧方法，因为条件仅是引发异常，然后返回的值仅表示没有异常。 一个更好的例子是R_RESULT = ABAP_FALSE，而不是两个RAISE EXCEPTION TYPE。

EDIT：在您的评论和Jelena的评论之后，我意识到我对条件的理解不佳，您为false或 true或引发异常。 也许一种更好的风格是，首先关注您分配的值，因为这全都与构造函数表达式有关，并且仅在其他情况下（例如，当...则为abap_true时，然后为abap_false否则为ELSE THROW异常）才引发异常。 我认为COND内的Throw异常是为了确定ELSE中的异常情况，主要目的是在THEN中，所以您所做的与之相反。 在您的示例中，以经典方式查看它可能会更"干净"，因为如果IF作为分支条件工作，则此后您可以执行任何操作。 使用COND，应该明确其目的：建立返回值（R_RESULT = true或false）或确定异常。

很高兴看到这样的问题至少偶尔出现一次 。 ：）

只有我的0.02美元。 我认为在这种情况下，我们处在样式范围内，而不是对或错，而是个人偏好而不是其他任何事情。

有了免责声明，在这种情况下，我更喜欢IF ...版本，因为我 可以更轻松地跟随它。 这不是因为我是不喜欢COND的ABAPosaur，而是因为正如其他人所述，在这里例外与值分配混在一起。 如果不是这种情况，那么COND选项可能会更好。

作为旁注，无论哪种情况，它都会使我感到困惑，如果i_param是INITIAL，但是第二个AND UTILITY ...条件不是 完整的IF语句将被跳过。 仅仅通过查看代码，我就无法判断它是故意的还是疏忽大意。 同样，我通常也不喜欢许多嵌套的IF，但是在这种特殊情况下，我感觉像是将第一个IF ... AND ...分解为单独的语句，这将允许将ELSEIF ...更改为简单的ELSE。 这样可以减少冗长，并且从调试的角度来看更方便。 正如Sandra正确指出的那样，对于自动化测试而言，这不是问题。

我会保留原来的方式，因为条件仅是引发异常，然后返回的值仅是表明没有异常。/em>

这就是我质疑功能性表达的原因。 我会将异常提取到（专用）预检查方法中，然后确定R_RESULT。