异常处理

RabbitMQ Java 客户端的许多操作都可能抛出受检查的异常。例如，在许多情况下可能会抛出 IOException 实例。RabbitTemplate、SimpleMessageListenerContainer 和其他 Spring AMQP 组件会捕获这些异常，并将其转换为 AmqpException 层次结构中的某个异常。这些异常在 'org.springframework.amqp' 包中定义，AmqpException 是该层次结构的基类。

当监听器抛出异常时，它会被包装在 ListenerExecutionFailedException 中。通常情况下，消息会被代理拒绝并重新入队。将 defaultRequeueRejected 设置为 false 会导致消息被丢弃（或路由到死信交换器）。如 消息监听器和异步情况 中所述，监听器可以抛出 AmqpRejectAndDontRequeueException（或 ImmediateRequeueAmqpException）来有条件地控制此行为。

然而，有一类错误是监听器无法控制其行为的。当遇到无法转换的消息（例如，无效的 content_encoding 头）时，在消息到达用户代码之前会抛出一些异常。如果 defaultRequeueRejected 设置为 true（默认值）（或抛出 ImmediateRequeueAmqpException），此类消息将一次又一次地被重新投递。在 1.3.2 版本之前，用户需要编写自定义的 ErrorHandler，如 异常处理 中所述，以避免这种情况。

从 1.3.2 版本开始，默认的 ErrorHandler 现在是 ConditionalRejectingErrorHandler，它会拒绝（并且不重新入队）因不可恢复错误而失败的消息。具体来说，它会拒绝因以下错误而失败的消息：

您可以为该错误处理器配置一个 FatalExceptionStrategy 实例，以便用户可以提供自己的条件消息拒绝规则 — 例如，一个委托实现到 Spring Retry 的 BinaryExceptionClassifier（消息监听器和异步情况）。此外，ListenerExecutionFailedException 现在有一个 failedMessage 属性，您可以在决策中使用它。如果 FatalExceptionStrategy.isFatal() 方法返回 true，则错误处理器将抛出 AmqpRejectAndDontRequeueException。默认的 FatalExceptionStrategy 在异常被确定为致命时会记录警告消息。

自 1.6.3 版本以来，将用户异常添加到致命列表的一个便捷方法是子类化 ConditionalRejectingErrorHandler.DefaultExceptionStrategy 并重写 isUserCauseFatal(Throwable cause) 方法，使其对于致命异常返回 true。

处理 DLQ 消息的常见模式是为这些消息设置一个 time-to-live 以及额外的 DLQ 配置，以便这些消息过期并被路由回主队列进行重试。这种技术的缺点是导致致命异常的消息会无限循环。从 2.1 版本开始，ConditionalRejectingErrorHandler 会检测到导致致命异常的消息上的 x-death 头部。该消息将被记录并丢弃。您可以通过将 ConditionalRejectingErrorHandler 上的 discardFatalsWithXDeath 属性设置为 false 来恢复到之前的行为。