異常處理

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 來恢復到之前的行為。