您好塞巴斯蒂安·科伊特卡

在我们的情况下，我们正在通过ATC处理它。 使用已读内容非常普遍，因此我们将其视为高优先级错误，应将其固定为错误而不只是警告

谢谢

nabheet

Quynhdoan Manh 表表达式带有引发此异常的固有风险。 就像方法的" raising"子句中有例外一样。 因此，如果未捕获到异常，则编译器可以对每个表表达式发出此警告。 对我来说似乎不太复杂。

就像Thanga Prakash解释的那样，还有其他方法可以在不使用上述异常处理的情况下编写表表达式

具有DEFAULT/OPTIONAL加法的VALUE构造运算符

DATA（ls_itab）= VALUE#（itab [component = ]可选）。

请参阅Horst Keller的博客

https ：//blogs.sap.com/2014/10/06/abap-news-for-740-sp08-more-for-internal-tables/

仅继承了异常 如果没有在方法的签名中声明或在该方法的签名中进行处理，CX_STATIC_CHECK会提供语法检查警告。

在我的很多使用案例中，都可以确保读取操作将始终成功 ，因此对于CX_SY_ITAB_LINE_NOT_FOUND是动态异常，我很好。

如果您的编码约定要求始终对此进行处理，则可以使用ATC检查作为 Nabheet Madan 建议（我不知道对此是否有任何标准检查，但如果不能，可以写一个。）

嗨 塞巴斯蒂安·科伊特卡

我们也可以使用以下方法编写。 在这种情况下，不需要在表表达式之后提供语法警告CX_SY_ITAB_LINE_NOT_FOUND。

如果您查看" table_exp-表表达式"的F1帮助，则将CX_SY_ITAB_LINE_NOT_FOUND称为可处理的异常。

例如 OPEN DATASET中也提到了许多可处理的异常，在大多数地方，我在编程中都未处理这些异常。

可能是SAP允许它作为使用这些异常的选择/不是/p>

将itab [KEY primary_key field = ls_str-field]分配到FIELD-SYMBOL（）。
   如果已分配。
    ......
   万一。
 

CX_SY_ITAB_LINE_NOT_FOUND继承自CX_DYNAMIC_CHECK。 如异常类别中的描述，我认为您想要什么 必须在ATC中处理