您可以将消息流设计为在返回到输入节点之前捕获异常。在单个流内,可以包含一个或多个 TryCatch 节点,为一系列节点提供单个故障点。您可以使用此方法提供非常具体的错误处理和恢复。
TryCatch 节点不以任何方式处理消息,它只代表消息流中的判定点。当 TryCatch 节点接收消息时,它将消息传播到 try 终端。代理将控制权传递给连接到该终端(尝试流)的一系列节点。
如果在尝试流中抛出异常,则代理会将控制权返回给 TryCatch 节点。该节点将 ExceptionList 的当前内容写至本地错误日志,然后将当前异常的信息写至 ExceptionList,覆盖该处存储的信息。
该节点随即将消息传播到连接到 catch 终端(catch 流)的一系列节点。所传播的消息树内容与传播到 try 终端的内容相同,即 TryCatch 节点首次收到该树时它的内容。它向该树添加写至 ExceptionList 的新异常信息。节点在尝试流中对消息树所作的任何修改或增补都不会显示在传播到 catch 流的消息树中。
然而,如果尝试流已对涉及外部数据库的更新完成处理,则这些更新不会丢失。当 catch 流处理消息时,这些更新会持续存在,有关是落实还是回滚这些更新的决策将在消息流的配置和与数据库交互的单独节点中作出。如果根据您设置的配置落实了这些更新,必须在 catch 流中包含回滚所作更改的逻辑。
要查看配置选项,请参阅为协调消息流配置节点。
在以下情况下,代理会将控制权交还给消息流中的下一个捕获点(可能是另一个 TryCatch 节点,但在最后一种情况中总是输入节点):
以下示例显示了如何配置流来捕获输入节点中的异常。MQInput 节点的 catch 终端连接到 Trace 节点以记录错误。
在以下示例中,消息流具有两个单独的处理流,连接到 Filter 节点的 true 终端和 false 终端。此处在消息能采用的两条路径的每一条中都包含了 TryCatch 节点。这两个TryCatch 终端的 catch 终端都连接到一个公共的错误处理子流。
如果您消息流中的输入节点没有 catch 终端(例如 Real-timeInput),而您希望在流中处理错误,则必须包含 TryCatch 节点。以下示例显示了可以如何连接流来提供此错误处理。在此示例中,您可以在 catch 流上的 Compute 节点中配置 ESQL 来检查已捕获的异常,并动态设置输出队列名称。