title: What is the idiomatic Java 8 way of handling a CompletableFuture that often cannot return a valid result?
body: <p>Let's say we are calling a slow remote service to get a <code>String</code> response. To do this we call a method that looks like this:</p>
  
  <pre><code>public CompletableFuture&lt;String&gt; getSlowly(String param) {...}
  </code></pre>
  
  <p>In this scenario, we also know we know that the service will not return a useful response in 20% of the times we call it. So 20% of the times we call <code>getSlowly</code> we will get an exceptionally completed future with some wrapped exception. Meaning, we will end up in the <code>catch</code> block of the following call:</p>
  
  <pre><code>try {
      String response = getSlowly("some input").join();
      doSomething(response); // 80% succeed
  catch (Exception e) {
      LOG.warn("Couldn't get response. Too bad."); // 20% fail
  }
  </code></pre>
  
  <p>This call is not critical and our application can gracefully handle the missing response. However, we do want to use the response whenever we do manage to get one successfully.</p>
  
  <p>Because we know that this failure will happen often, i.e. we do <em>expect</em> it, does it make sense to treat these 20% of calls as <em>exceptional</em>?</p>
  
  <p>One way of not treating the 20% as exceptional would be to change the implementation of <code>getSlowly</code> to something like this:</p>
  
  <pre><code>public CompletableFuture&lt;Optional&lt;String&gt;&gt; getSlowly(String param) {...}
  </code></pre>
  
  <p>This looks unwieldy.</p>
  
  <p>Is there an idiomatic way we should handle such flaky CompletableFutures? Should we consider it an exceptional state when a return value is missing, or should we instead return optionals (or similar custom objects)?</p>