title: async void event handlers - clarification?
body: <p>I'm trying to understand the reason <em>why</em> is it bad to do: <em>(notice, context here is asp.net, regardless the plain reason that <code>async void</code> can't be tracked)</em></p>
  
  <pre><code> public async void Page_Load(object sender, EventArgs e)
  {
   ...
  }
  </code></pre>
  
  <p>Well , after investigating a bit I saw few <em>different</em> reasons :</p>
  
  <ul>
  <li><p>Damian Edwards Says <a href="http://www.hanselman.com/blog/TheMagicOfUsingAsynchronousMethodsInASPNET45PlusAnImportantGotcha.aspx" rel="nofollow noreferrer">here</a>  that:</p>
  
  <blockquote>
    <p>Async void event handlers in web forms <strong>are only supported on certain
    events</strong>, as you've found, but are really only intended for simplistic
    tasks. We recommend using PageAsyncTask for any async work of any real
    complexity.</p>
  </blockquote></li>
  <li><p>Levi  Says <a href="http://www.hanselman.com/blog/TheMagicOfUsingAsynchronousMethodsInASPNET45PlusAnImportantGotcha.aspx" rel="nofollow noreferrer">here</a>  that: </p>
  
  <blockquote>
    <p>Async events in web applications are inherently strange beasts. Async
    void is meant for a fire and forget programming model. This works in
    Windows UI applications since the application sticks around until the
    OS kills it, so whenever the async callback runs there is guaranteed
    to be a UI thread that it can interact with. In web applications, this
    model falls apart since requests are by definition transient. <strong>If the
    async callback happens to run after the request has finished, there is
    no guarantee that the data structures the callback needs to interact
    with are still in a good state</strong>. Thus why fire and forget (and async
    void) is inherently a bad idea in web applications.</p>
    
    <p>That said, we do crazy gymnastics to try to make very simple things
    like Page_Load work, but the code to support this is extremely
    complicated and not well-tested for anything beyond basic scenarios.
    So if you need reliability I’d stick with RegisterAsyncTask.</p>
  </blockquote></li>
  <li><p><a href="http://codewala.net/tag/async/" rel="nofollow noreferrer">This site</a> says: </p>
  
  <blockquote>
    <p>As we know
    our page life cycle has a set of events that gets fired in a
    predefined order <strong>and next event will be fired only when the last event
    completes.</strong> So if we use the above way of async Page_Load, this event
    will be fired during page life cycle event once it reaches to async,
    current thread gets free and a another thread got assigned to complete
    the task asynchronously, <strong>but the ASP.NET cannot execute the next event
    in life cycle because Page_Load has not been completed yet</strong>. And
    underlying synchronization context waits till the asynchronous
    activity completes. Then only the next event of page lifecycle will be
    fired which makes the whole process in synchronous mode only.</p>
  </blockquote></li>
  <li><p><a href="http://msdn.microsoft.com/en-us/magazine/jj991977.aspx" rel="nofollow noreferrer">This</a> site says</p>
  
  <blockquote>
    <p><strong>when the return type is void, the
    caller might assume the method is complete by the time it returns</strong>.
    This problem can crop up in many unexpected ways. It’s usually wrong
    to provide an async implementation (or override) of a void-returning
    method on an interface (or base class). <strong>Some events also assume that
    their handlers are complete when they return</strong>.</p>
  </blockquote></li>
  </ul>
  
  <p>I see here very <strong>different</strong>  (non-overlapping) reasons.</p>
  
  <p><strong>Question :</strong> </p>
  
  <p><strong>What</strong> is the glory/true reason for which we shouldn't write <code>public async void Page_Load(object sender, EventArgs e)</code> ?</p>
  
  <hr>
  
  <p>nb, I also don't know why it is a problem since 4.5 does use the <a href="http://msdn.microsoft.com/en-us/library/hh975440.aspx" rel="nofollow noreferrer">UseTaskFriendlySynchronizationContext</a> which its  <a href="https://stackoverflow.com/a/9662023/859154">aim is to support</a>:</p>
  
  <p><code>protected async void Page_Load(object sender, EventArgs e){...}</code></p>