anchor.diff:  ==== Using resources and the finally block
   The last parallel to draw with the imperative world is the cleaning up that can
   be done either via a Java 7 "try-with-resources" construct or the use of the
  -`finally` block (*(5)*). Both have their Reactor equivalent, actually: `using`
  +`finally` block (*(6)*). Both have their Reactor equivalent, actually: `using`
   and `doFinally`:
   [source,java]
   ----
  
positive.code: ==== Log or react on the side
  For cases where you want the error to continue propagating, but you still want
  to react to it without modifying the sequence (for instance logging it like in
  item *(4)*), there is the `doOnError` operator. This operator as well as all
  `doOn` prefixed operators are sometimes referred to as a "side-effect". That is
  because they allow to peek inside the sequence's events without modifying them.
  
  
negative.code: make a parallel with imperative world's `try` patterns.
  
  === Error handling operators
  You may be familiar with several ways of dealing with exceptions in a try/catch
  block. Most notably:
  
   1. catch and return a static default value
   2. catch and execute an alternative path (fallback method)
   3. catch and dynamically compute a fallback value
   4. catch, wrap to a `BusinessException` and re-throw
   5. catch, log an error specific message and re-throw
   6. the `finally` block to clean up resources, or a Java 7's "try-with-resource" construct
  
  All of these have equivalent in Reactor, in the form of error handling operators.
  
  Before looking into these operators, let's first try to establish a parallel between a
  reactive chain and a try-catch block.
  
  When subscribing, the `onError` callback at the end of the chain is akin to a `catch`
  block. There, execution skips to the catch in case an Exception is thrown:
  [source,java]
  ----
  Flux<String> s = Flux.range(1, 10)
  