anchor.diff:  referred to as a "side-effect". They let you peek inside the sequence's events without
   modifying them.
   
  -Like the imperative example above, the following example ensures that when we
  -fallback to the cache, we at least log that the external service had a failure.
  +Like the imperative example above, the following example still propagates the error yet
  +ensures that we at least log that the external service had a failure.
   We can also imagine we have statistic counters to increment as a second error side-effect.
   
   [source,java]
  
positive.code:             failureStat.increment();
              log("uh oh, falling back, service failed for key " + k); // <2>
          })
          .onErrorResume(e -> getFromCache(k)) // <3>
      );
  ----
  <1> The external service call that can fail...
  <2> ...is decorated with a logging and stats side-effect...
  <3> ...and then protected with the cache fallback.
  
  ==== Using Resources and the Finally Block
  The last parallel to draw with imperative programming is the cleaning up that can be done
  
negative.code: try {
    return callExternalService(k);
  }
  catch (RuntimeException error) {
    //make a record of the error
    log("uh oh, falling back, service failed for key " + k);
    throw error;
  }
  ----
  
  