关于 mulesoft error handling 的一点总结
Error Handling 的两种类型
On Error Continue
错误在这里处理后会继续向上层 flow 的下一个组件传递, 默认情况下返回的是 payload, 状态码为 200
On Error Propagate
错误在这里处理后会继续向上层 flow 的 Error Handling 传递, 默认情况下返回的是 error.description 状态码为 500.
默认情况下 flow 返回的内容.
放置 Error Handling 的地方:
有三个地方可以放置 Error Handling, 分别为 Flow, Try, Global.
Global 中的 Error Handling: 如果一个 Flow 没有 Error Handling, 那么该 Flow 中有组件抛出错误时会在 Global寻找匹配的 Error Handling 处理错误.
自带了 Error Handling 的 Flow 会忽略 Global Error Handling, 即使自己没有匹配的 Error Handling.
如果不设 Error Handling, 在错误发生时, 会调用默认的 Error Handling.
try 中错误处理顺序 (假设为 Propagate): error try -> error main
例子
A flow 调用 B flow, B flow 中有错误抛出
B Continue
这种情况下, B 中的 Is number 抛出错误, 在 error main b 中处理, 返回 error main b 至 A, A 继续向下运行到 main a, 最终客户端将收到内容为 main a, 状态码为 200 的信息.
B Propagate / A Continue
这种情况下, B 中的 Is number 抛出错误, 在 error main b 中处理, 处理后继续向 A 抛出错误处理, A 收到错误后在 error main a 中处理, 并返回 error main a. 最终客户端收到的是内容为 error main a, 状态码为 200 的信息.
B 中的 error main a 虽然有被执行, 但其值并没有被抛向 A. A 收到的错误内容为 Is number 产生的 Not number.
B Propagate / A Propagate
这种情况下, B 中情形与上面的情形一致, A 收到错误后在 main error a 中处理, 返回的是 B 传过来的错误信息 Not number. 最终客户端收到内容为 Not number, 状态码为 500 的信息.
A 中的 error main a 虽然被执行, 但其值不会被返回.
A flow 向 B flow 发出请求, B flow 中有错误抛出
B Continue
如图所示, B 中的 Error Handling 为 Continue, 所以当 Is number 抛错时, B 总返回 error main 2, 状态码为 200.
A 接收到返回的内容没觉得有错误发生, 直接将 error main 2 和 200 状态码返回给客户端.
可以看出这种情形下 A 的 Error Handling 是没有起作用的.
B Propagate / A Continue
当 B 中的 Error Handling 为 Propagate 时, Is number 抛错, B 将返回 Not number, 状态码为 500.
因为默认情况下, flow 在错误发生时返回的 body 为 error.description. 因此, B 中的 error main 2 虽然被执行了, 但并不会被返回.
A 中的 Request 收到了内容为 Not number, 状态码为 500 的返回信息, 交由 error main 1 处理, 由于是 Continue, 所以 A 将返回 error main 1, 200 状态给客户端.
B Propagate / A Propagate
这种情况下, B 中情形与上面的情形一致, 主要区别在 A:
由于 A 中的 Error Handling 为 Propagate, 因此, A 将返回 错误码为B 500, 内容为 HTTP GET on resource ‘http://127.0.0.1:8081/B' failed: internal server error (500). 的信息给客户端.
由于默认情况下 A flow 在发生错误时返回的是 error.description, 因此 A 中的 error main 1 虽然被执行了, 但其内容不会被返回.