📅 最后修改于: 2020-11-12 05:05:36 🧑 作者: Mango
对于每个项目，有关异常的事实是它们一定会发生。这就是为什么捕获，分类和处理异常很重要，这样系统/应用程序才不会处于不一致的状态。有一个默认的例外策略，该策略隐式应用于所有Mule应用程序。自动回滚任何未决的事务是默认的例外策略。
在深入研究异常处理之前，我们应该了解什么样的异常会发生，以及开发人员在设计异常处理程序时必须遇到的三个基本问题。
在设计异常处理程序之前，此问题具有足够的相关性，因为所有传输都不支持跨国性。
文件或HTTP不支持事务。因此，如果在这些情况下发生异常，我们必须手动进行管理。
数据库支持事务。在这种情况下设计异常处理程序时，我们必须记住，数据库事务可以自动回滚(如果需要)。
对于REST API ，我们应该记住，它们应该返回正确的HTTP状态代码。例如，找不到资源的404。
在设计异常处理程序时，我们必须注意消息交换模式。可以有同步(请求-答复)或异步(即忘了)消息模式。
同步消息模式基于请求-应答格式，这意味着该模式将期望响应，并且将被阻塞，直到返回响应或发生超时。
异步消息模式基于即发即弃格式，这意味着该模式假定最终将处理请求。
非常简单的规则是，您将根据异常的类型处理异常。知道异常是由系统/技术问题还是业务问题引起的，这一点非常重要。
由系统/技术问题(例如网络中断)引起的异常应由重试机制自动处理。
另一方面，业务问题发生的异常(例如无效数据)不应通过应用重试机制来解决，因为在不解决根本原因的情况下重试是没有用的。
我们知道所有异常都不相同，因此对异常进行分类非常重要。从总体上讲，异常可以分为以下两种类型：
发生业务异常的主要原因是不正确的数据或不正确的流程。这类异常通常本质上是不可重试的，因此配置回滚是不好的。即使应用重试机制也没有任何意义，因为在不解决根本原因的情况下重试是没有用的。为了处理此类异常，处理应立即停止，并将异常作为对死信队列的响应发送回去。通知也应发送给操作。
发生非业务异常的主要原因是系统问题或技术问题。这些异常本质上是可重试的，因此最好配置重试机制以解决这些异常。
Mule具有以下五种异常处理策略-
Mule将这种策略隐式地应用于Mule流。它可以处理流程中的所有异常，但是也可以通过添加catch，Choice或Rollback异常策略来覆盖它。该异常策略将回滚任何未决的事务，并记录异常。此异常策略的一个重要特征是，如果没有事务，它将也记录异常。
作为默认策略，当流程中发生任何错误时，Mule都会实施此策略。我们无法在AnyPoint Studio中进行配置。
假设如果没有纠正错误的可能解决方案，那该怎么办?一种解决方案是使用回滚异常策略，该策略将回滚事务并将消息发送到父流的入站连接器以重新处理消息。当我们要重新处理消息时，此策略也非常有用。
例
此策略可应用于将资金存入支票/储蓄帐户的银行交易。我们可以在此处配置回滚异常策略，因为如果在事务期间发生错误，该策略会将消息回滚到流程的开头以重新尝试处理。
此策略捕获在其父流中引发的所有异常。它通过处理父流抛出的所有异常来覆盖Mule的默认异常策略。我们可以使用catch异常策略来避免将异常传播到入站连接器和父流。
此策略还可以确保在发生异常时不回退由流处理的事务。
例
该策略可以应用于航班预订系统，在该系统中，我们有一个流程来处理来自队列的消息。消息丰富器在消息上添加属性以分配席位，然后将消息发送到另一个队列。
现在，如果此流程中发生任何错误，则该消息将引发异常。在这里，我们的catch异常策略可以添加带有适当消息的标头，并将该消息从流中推送到下一个队列。
如果您要根据消息内容处理异常，则选择异常策略将是最佳选择。该异常策略的工作如下-
在选择异常策略中定义了不止一种异常策略，例如Catch或Rollback。如果在此异常策略下未定义策略，则它将消息路由到默认的异常策略。它从不执行任何提交或回滚或消耗活动。
这是指在单独的配置文件中定义的常见异常策略。如果消息引发异常，则此异常策略将引用在全局捕获，回滚或选择异常策略中定义的错误处理参数。像选择异常策略一样，它从不执行任何提交或回滚或消耗活动。