anchor.diff:  }
   ```
   
  -and you only want to enable DLQ on the first input binding and logAndSkip on the second binding, then you can do so on the consumer as below.
  +and you only want to enable DLQ on the first input binding and skipAndContinue on the second binding, then you can do so on the consumer as below.
   
   `spring.cloud.stream.kafka.streams.bindings.process-in-0.consumer.deserializationExceptionHandler: sendToDlq`
  -`spring.cloud.stream.kafka.streams.bindings.process-in-1.consumer.deserializationExceptionHandler: logAndSkip`
  +`spring.cloud.stream.kafka.streams.bindings.process-in-1.consumer.deserializationExceptionHandler: skipAndContinue`
   
   Setting deserialization exception handlers this way has a higher precedence than setting at the binder level.
   
  
positive.code: This is because there is no way for the binder to infer the names of all the DLQ topics the implementation might send to.
  Therefore, if you provide DLQ names using this strategy, it is the application's responsibility to ensure that those topics are created beforehand.
  
  If `DlqDestinationResolver` is present in the application as a bean, that takes higher prcedence.
  If you do not want to follow this approach and rather provide a static DLQ name using configuration, you can set the following property.
  
  [source]
  
negative.code: deserializationExceptionHandler::
  Deserialization error handler type.
  This handler is applied per consumer binding as opposed to the binder level property described before.
  Possible values are - `logAndContinue`, `logAndFail`, `skipAndContinue` or `sendToDlq`
  +
  Default: `logAndFail`
  
  