anchor.diff:  However, when all fails, the exceptions thrown by the message handlers are propagated back to the binder. At that point, binder invokes custom error handler or communicates
   the error back to the messaging system (re-queue, DLQ, and others).
   
  -===== Application Error Handling
  +==== Application Error Handling
   
   There are two types of application-level error handling. Errors can be handled at each binding subscription or a global handler can handle all the binding subscription errors. Let's review the details.
   
  
positive.code: 
  This effectively combines application-level and system-level error handling to further assist with downstream troubleshooting mechanics.
  
  ====== Re-queue Failed Messages
  
  As mentioned earlier, the currently supported binders (Rabbit and Kafka) rely on `RetryTemplate` to facilitate successful message processing. See <<Retry Template>> for details.
  However, for cases when `max-attempts` property is set to 1, internal reprocessing of the message is disabled. At this point, you can facilitate message re-processing (re-tries)
  
negative.code: 
  This may be a convenient option if error handling logic is the same regardless of which handler produced the error.
  
  ==== System Error Handling
  
  System-level error handling implies that the errors are communicated back to the messaging system and, given that not every messaging system
  is the same, the capabilities may differ from binder to binder.
  