Mulesoft 简明教程

MuleSoft - Mule Exception handling

对于每个项目，一个事实是肯定会发生例外。这就是捕获、分类和处理异常非常重要的原因，从而系统/应用程序不会处于不一致的状态。有一个默认异常策略，它隐式应用于所有 Mule 应用程序。自动回滚任何待处理事务是默认异常策略。

In case of every project, the fact about the exceptions is that they are bound to happen. That is why it is important to catch, categorize and handle exceptions so that the system/application is not left in an inconsistent state. There is a default exception strategy which is implicitly applied to all Mule applications. Rollback any pending transaction automatically is the default exception strategy.

Exceptions in Mule

在深入研究异常处理之前，我们应该了解会发生哪种异常以及开发人员在设计异常处理程序时必须具备的三个基本问题。

Before diving deep into exceptional handling, we should understand what kind of exceptions can occur along with three basic questions that a developer must have while designing exception handlers.

Which Transport is important?

在设计异常处理程序之前，此问题非常相关，因为并非所有传输都支持跨国性。

This question has ample relevance before designing exception handlers because all transports do not support transnationality.

File 或 HTTP 不支持事务。因此，如果在这些情况下发生异常，我们必须手动对其进行管理。

File or HTTP does not support transactions. That is why, if an exception occurs in these cases, we must manage it manually.

Databases 支持事务。在这种情况下设计异常处理程序时，我们必须记住数据库事务可以自动回滚（如果需要的话）。

Databases support transactions. While designing exception handlers in this case, we must keep in mind that database transactions can automatically rollback (if required).

对于 REST APIs ，我们应该记住它们应该返回正确的 HTTP 状态码。例如，资源未找到时为 404。

In case of REST APIs, we should keep in mind that they should return the correct HTTP status codes. For example, 404 for a resource not found.

Which Message Exchange Pattern to be used?

在设计异常处理程序时，我们必须注意消息交换模式。可以有同步（请求-响应）或异步（防火）消息模式。

While designing exception handlers, we must take care about Message exchange pattern. There can be synchronous (request-reply) or asynchronous (fire-forget) message pattern.

Synchronous message pattern 基于请求-响应格式，这意味着此模式将期待响应，并且在返回响应或超时之前将被阻塞。

Synchronous message pattern is based on request-reply format which means this pattern will expect a response and will be blocked until a response is returned or time out happens.

Asynchronous message pattern 基于防火格式，这意味着此模式假定最终将处理请求。

Asynchronous message pattern is based on fire-forget format which means this pattern assumes that the requests will ultimately be processed.

Which type of exception is it?

非常简单的规则是，你将根据异常的类型来处理该异常。了解这个异常是由系统/技术问题还是业务问题引起的非常重要？

Very simple rule is that you will handle the exception based on its type. It is very important to know whether the exception is caused by a system/technical issue or a business issue?

system/technical issue 发生的异常（例如网络中断）应该由重试机制自动处理。

An exception occurred by system/technical issue (such as network outage) should be automatically handled by a retry mechanism.

另一方面， by a business issue 发生的异常（例如无效数据）不应该通过应用重试机制来解决，因为在未修复根本原因的情况下，重试是没有用的。

On the other hand, an exception occurred by a business issue (such as invalid data) should not be solved by applying retry mechanism because it is not useful to retry without fixing the underlying cause.

Why to Categorize Exceptions?

众所周知，并非所有异常都是相同的，因此对异常进行分类非常重要。从高层面上讲，可以将异常分类为以下两种类型 −

As we know that all the exceptions are not same, it is very important to categorize the exceptions. At high level, the exceptions can be classified into the following two types −

Business Exceptions

业务异常发生的主要原因是错误的数据或不正确的流程流。此类异常通常本质上不可重试，因此配置 rollback 不好。即使应用 retry 机制也没有任何意义，因为在不修复根本原因的情况下，重试是没有用的。为了处理此类异常，应立即停止处理，并将异常作为对死信队列响应发送回。还应该向运维发送通知。

The main reasons for the occurrence of business exceptions are incorrect data or incorrect process flow. These kind of exceptions are typically non-retriable in nature and hence it is not good to configure a rollback. Even applying retry mechanism would not make any sense because it is not useful to retry without fixing the underlying cause. In order to handle such exceptions, the processing should stop immediately, and the exception sent back as a response to a dead letter queue. A notification should also send to the operations.

Non-business Exceptions

非业务异常发生的主要原因是系统问题或技术问题。这类异常本质上是可重试的，因此为了解决这些异常，最好配置 retry 机制。

The main reasons for the occurrence of non-business exceptions are system issue or technical issue. These kinds of exceptions are retriable in nature and hence it’s good to configure a retry mechanism in order to solve these exceptions.

Exception Handling Strategies

Mule 有以下五种异常处理策略 −

Mule has the following five exception handling strategies −

Default Exception Strategy

Mule 隐式地将此策略应用于 Mule 流程。它可以处理我们流程中的所有异常，但是也可以通过添加 catch、选择或回滚异常策略来覆盖它。此异常策略将回滚任何待定的事务并记录异常。此异常策略的一个重要特征是，如果没有事务，它还将记录异常。

Mule implicitly applies this strategy to the Mule flows. It can handle all the exceptions in our flow, but it can also be overridden by adding a catch, Choice or Rollback exception strategy. This exception strategy will roll back any pending transactions and logs the exceptions too. An important characteristic of this exception strategy is that it will also log the exception if there is no transaction.

作为默认策略，Mule 在流中出现任何错误时实现此策略。我们无法在 AnyPoint Studio 中进行配置。

As being the default strategy, Mule implements this when any error occurs in the flow. We cannot configure in AnyPoint studio.

Rollback Exception Strategy

假设如果没有可能纠正错误的解决方案，该怎么办？一种解决方案是使用回滚异常策略，该策略将回滚事务，同时向父流程的入站连接器发送消息以重新处理消息。当我们想要重新处理消息时，此策略也非常有用。

Suppose if there is no possible solution to correct the error then what to do? A solution is to use Rollback Exception Strategy which will roll back the transaction along with sending a message to the inbound connector of parent flow to reprocess the message. This strategy is also very useful when we want to reprocess a message.

Example

此策略可以应用于资金存入支票/储蓄账户的银行交易中。我们可以在此处配置回滚异常策略，因为如果在交易过程中发生错误，此策略会将消息回滚到流的开头，以重新尝试处理。

This strategy can be applied to banking transaction where funds are getting deposited in a checking/savings account. We can configure a rollback exception strategy here because in case if an error occurs during the transaction, this strategy rolls the message back to the beginning to the flow to reattempt processing.

Catch Exception Strategy

此策略捕获其父流程中引发的所有异常。它通过处理父流程引发的所有异常来覆盖 Mule 的默认异常策略。我们可以使用 catch 异常策略来避免将异常传播到入站连接器和父流程。

This strategy catches all the exceptions that are thrown within its parent flow. It overrides Mule’s default exception strategy by processing all the exceptions thrown by the parent flow. We can use a catch exception strategy to avoid propagating exceptions to inbound connectors and parent flows as well.

此策略还确保在发生异常时不会回滚流处理的事务。

This strategy also ensures that a transaction processed by the flow is not rolled back when an exception occurs.

Example

此策略可以应用于航班预订系统，其中我们有一个用于处理来自队列的消息的流程。消息丰富器在消息中添加了一个属性以分配座位，然后将消息发送到另一个队列。

This strategy can be applied to flight booking system in which we have a flow for processing messages from a queue. A message enricher adds a property on the message for assignment of seat and then sends the message to another queue.

现在，如果此流程中发生任何错误，则消息将引发异常。在这里，我们的 catch 异常策略可以添加一个带有适当消息的标头，并可以将该消息从流程推送到下一个队列。

Now if any error occurs in this flow, then the message will throw an exception. Here, our catch exception strategy can add a header with an appropriate message and can push that message out of the flow to the next queue.

Choice Exception Strategy

如果您想根据消息内容来处理异常，那么选择异常策略将是最佳选择。此异常策略的工作方式如下 −

In case you want to handle the exception based on the message content, then choice exception strategy would be the best choice. The working of this exception strategy will be as follows −

  1. First, it catches all the exceptions thrown within the parent flow.

  2. Next, it checks for the message content and exception type.

  3. And at last, it routes the message to the appropriate exception strategy.

在选择异常策略中，会有多个异常策略，例如 Catch 或 Rollback。如果没有在此异常策略中定义任何策略，它会将消息路由到默认异常策略。它不会执行任何提交或回滚或消费活动。

There would be more than one exception strategy like Catch or Rollback, defined within choice exception strategy. In case there is no strategy defined under this exception strategy, then it will route the message to the default exception strategy. It never performs any commit or rollback or consume activities.

Reference Exception Strategy

这涉及一个在独立配置文件中定义的常见异常策略。如果消息引发异常，此异常策略会引用在全局 catch、rollback 或 choice 异常策略中定义的错误处理参数。与 choice 异常策略一样，它也不会执行任何 commit 或 rollback 或消费活动。

This refers to a common exception strategy that is defined in a separate configuration file. In case when a message throws an exception, this exception strategy will refer to the error handling parameters defined in a global catch, rollback or choice exception strategy. Like choice exception strategy, it never performs any commit or rollback or consume activities also.