首先，我提出了我案件的背景：
我正在使用spring-boot和spring-rabbitmq。这对我有用，你应该知道我必须为收到的消息实现自定义转换器
（1）从此转换器可以抛出异常，例如在不正确的消息等情况下。
（2）成功转换（无异常）后，将调用侦听器。然后，在监听器中它也可以抛出异常。
现在，我想强制两件事：
（1'）如果在转换器中出现故障，请不要重新排队。只需将确认发送到队列并模拟一切正常
（2'）在这种情况下，默认设置是什么？当内部spring-rabbitmq engine决定向队列发送确认时？当它决定重新排队的命令？是否有可能根据情况进行管理？
我在docs中找到了：
如果未启用重试且侦听器抛出异常，则按 默认情况下，交付将无限期重试。你可以修改它 行为有两种方式;将defaultRequeueRejected属性设置为false 将尝试零重新交付;或者，扔一个 AmqpRejectAndDontRequeueException应该是消息的信号 被拒绝。这是启用重试时使用的机制 达到最大传递次数。
例如，取决于监听器中的catched异常，我应该根据自己的想法决定是否要重新排队消息（只需从catch AmqpRejectAndDontRequeueException投掷）。我不确定这是不是很好的方式，这也是我问你的意见的原因。
答案 0 :(得分：0)
请阅读reference manual。
行为（主要）由ErrorHandler控制。
抛出一个MessageConversionException - 容器重新排列大多数异常的消息，但有些异常被认为是致命的。通常，如果邮件无法转换，则重新投放邮件毫无意义。
这一点在（令人惊讶的？）Exception Handling
部分清楚地解释了从版本1.3.2开始，默认的ErrorHandler现在是一个ConditionalRejectingErrorHandler，它将拒绝（而不是重新排队）因无法恢复的错误而失败的消息：
... o.s.amqp MessageConversionException
... o.s.messaging MessageConversionException
... o.s.messaging MethodArgumentNotValidException
... o.s.messaging MethodArgumentTypeMismatchException
java.lang.NoSuchMethodException
java.lang.ClassCastException
使用MessageConverter转换传入的消息有效负载时，可以抛出第一个。如果在映射到@RabbitListener方法时需要额外的转换，则转换服务可能抛出第二个。如果在侦听器中使用验证（例如@Valid）并且验证失败，则可能抛出第三个。如果入站消息转换为对目标方法不正确的类型，则可能抛出第四个。例如，参数声明为Message但接收到Message。
第1.6和第6版在版本1.6.3中添加。
您可以根据需要自定义ErrorHandler。