title: Is catching TaskCanceledException and checking Task.Canceled a good idea?
body: <p>There are some people on my team who really love coding with async <code>Task</code>. And sometimes they like to use <code>CancellationToken</code> parameters. </p>
  
  <p>What I'm unsure about is whether we should as a team be using this style of code (A):</p>
  
  <pre><code>async Task&lt;someObject&gt; DoStuff(CancellationToken t)
  {
      while (!t.IsCanceled)
      {
          try {
              Task.Delay(5000, t);
          }
          catch (AggregateException e) // or is it TaskCanceledException or OperationCanceledException? I don't know? :)
          {
          }
          // poll something, return someObject, or null
      }
      return null;
  }
  </code></pre>
  
  <p>This obviously means the caller probably has to check the cancellation token themselves to determine whether to continue processing, and they might have to handle null retVals:</p>
  
  <pre><code>var retVal = await DoStuff(token);
  if (token.IsCanceled) { ... }
  </code></pre>
  
  <p>However, if we adopt a second style of code (B) that relies on TaskCanceledException:</p>
  
  <pre><code>async Task&lt;someObject&gt; DoStuff(CancellationToken t)
  {
      while(true)
      {
          Task.Delay(5000, t);
          // poll something, return someObject, or null
      }
  }
  </code></pre>
  
  <p>The implementation code is definitely simpler - and the caller has the option of handling the exception or not, as appropriate... but I can't help worrying that callers might <em>forget</em> that TaskCanceledException is something they have to worry about, and processes may crash as a result of them not catching these exceptions (on foreground or background threads).</p>
  
  <p>So, my overly optimistically phrased question is: which do you think is the <em>best</em> style that <em>everyone</em> should <em>always</em> use, and why? :)</p>