title: Alternatives to bool TryGetX(out X x) pattern
body: <p>I often use the pattern </p>
  
  <pre><code>bool TryGetX(out X x)
  </code></pre>
  
  <p>when I need to get data from a service that may fail. I use this when neither the client nor the service can know if the data is available until trying to retrieve it. I've never been totally happy with using the <em>out</em> parameter that way, and I see from other SO questions that it is considered a poor pattern. </p>
  
  <p>However, I haven't seen a convincing alternative API that gives the client a hint that their method call may not actually return the data. </p>
  
  <p>Alternatives I've considered:</p>
  
  <ul>
  <li><p>X GetX(), where <em>GetX()</em> returns <em>null</em> if the service cannot provide the requested data. I don't like doing this since it isn't clear to many people that they need to check for <em>null</em> being returned. Given the number of null reference exceptions I encounter in legacy code I've worked on, people often neglect a null-check and the user gets an ugly exception box shown to them. At least the <em>TryGetX</em> approach is clear to the client that the data may not be returned. Even if they do check for null, is requiring a <em>if (x == null)</em> everywhere really better than <em>TryGetX(out X x)</em>?</p></li>
  <li><p>Try/Catch, where <em>GetX()</em> throws an exception if the data cannot be returned. Again, clients may not realize that <em>GetX()</em> throws an exception, and even if they do, you have Try/Catches sprinkled around the code.</p></li>
  <li><p>GetXResult GetX(), where the class <em>GetXResult</em> has two properties: <em>bool Success</em> and <em>X x</em>. This would probably be my preferred alternative, but then I have many result classes floating around, cluttering my project.</p></li>
  </ul>
  
  <p>What is the best approach for a method that returns data, but may not be able to return the data requested?</p>