21

I'm trying to understand what is going on with exceptions that are thrown within a task object and never handled.

On MSDN it said that:

If you do not wait on a task that propagates an exception, or access its Exception property, the exception is escalated according to the .NET exception policy when the task is garbage-collected.

So I don't quite understand in what way those exceptions affect program flow. I thought that those exceptions should interrupt execution as soon as they are garbage-collected. But I can not design this behaviour. Within the following snippet the thrown exception doesn't show up.

// Do something ...
Task.Run (()=> {throw new Exception("Exception in the task!");});
// Do something else

Please, can anyone explain how unhandled task exception are dealt with and how they affect program flow.

Jeff B
  • 8,572
  • 17
  • 61
  • 140
user3101007
  • 691
  • 2
  • 7
  • 18

2 Answers2

41

You're describing the behavior as it was in .NET 4, but it will be difficult for you to force the garbage collection and actually observe that behavior. The following quote from Stephen Toub's excelent write-up on the subject should make it even more clear:

Tasks keep track of whether an unhandled exception has been “observed.” In this context, “observed” means that code has joined with the Task in some fashion in order to at least be made aware of the exception. This could be calling Wait/WaitAll on the Task. It could be checking the Task’s Exception property after the Task has completed. Or it could be using a Task’s Result property. If a Task sees that its exception has been observed in some manner, life is good. If, however, all references to a Task are removed (making the Task available for garbage collection), and if its exception hasn’t yet been observed, the Task knows that its exception will never be observed. In such a case, the Task takes advantage of finalization, and uses a helper object to propagate the unhandled exception on the finalizer thread. With the behavior described earlier, that exception on the finalizer thread will go unhandled and invoke the default unhandled exception logic, which is to log the issue and crash the process.

He also suggested two useful extension methods for handling exceptions in "fire-and-forget" tasks: one ignoring the exception and the other one immediately crashing the process:

public static Task IgnoreExceptions(this Task task)
{
    task.ContinueWith(c => { var ignored = c.Exception; },
        TaskContinuationOptions.OnlyOnFaulted |
        TaskContinuationOptions.ExecuteSynchronously |
        TaskContinuationOptions.DetachedFromParent);
    return task;
}

public static Task FailFastOnException(this Task task)
{
    task.ContinueWith(c => Environment.FailFast("Task faulted", c.Exception),
        TaskContinuationOptions.OnlyOnFaulted |
        TaskContinuationOptions.ExecuteSynchronously |
        TaskContinuationOptions.DetachedFromParent);
    return task;
}

In .NET 4.5 the default behavior has changed. Again, a quote from another Stephen Toub's post on the subject (thanks to mike z for bringing it to my attention in the comments):

To make it easier for developers to write asynchronous code based on Tasks, .NET 4.5 changes the default exception behavior for unobserved exceptions. While unobserved exceptions will still cause the UnobservedTaskException event to be raised (not doing so would be a breaking change), the process will not crash by default. Rather, the exception will end up getting eaten after the event is raised, regardless of whether an event handler observes the exception. This behavior can be configured, though.

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Damir Arh
  • 17,637
  • 2
  • 45
  • 83
  • 6
    While this is correct for .NET 4, in .NET 4.5 the policy was changed to ignore unobserved task exceptions. – Mike Zboray Feb 08 '14 at 21:38
  • @mikez Thanks for bringing it to my attention. I've edited the answer accordingly. – Damir Arh Feb 09 '14 at 06:20
  • 1
    also according to [Stephen Toub](https://blogs.msdn.microsoft.com/pfxteam/2009/06/01/tasks-and-unhandled-exceptions/), _"Prior to its RTM (.net 4.0), the default was swapped such that DetachedFromParent is now the default, so you can just remove the DetachedFromParent from these code samples and they'll behave as intended. If you actually want the task attached, you can use AttachedToParent."_ – Lucas Sep 24 '16 at 19:02
  • This is the newer link for the quote in the post: https://devblogs.microsoft.com/pfxteam/task-exception-handling-in-net-4-5/ – ceiling cat Oct 07 '21 at 12:34
  • @ceilingcat thanks, I updated both links in my answer. – Damir Arh Oct 07 '21 at 15:07
6

Please note the code above is not quite correct. You must return the pointer to the task.ContinueWith, not the passed-in task:

public static Task IgnoreExceptions(this Task task)
{
    var t = task.ContinueWith(c => { var ignored = c.Exception; },
        TaskContinuationOptions.OnlyOnFaulted |
        TaskContinuationOptions.ExecuteSynchronously);
    return t;
}

EDIT:

This is challenging because it depends on how you chain your calls together. For example, the following call doesn't work the way I would expect:

public Task MyServiceCall()
{
  return Task.Run(() => DoSomething()).IgnoreExceptions();
}

This method does indeed throw exceptions because the the accepted answer returns the initial task (not the one which observes the exception). This could be problematic with other calls, such as .Wait, .WhenAll etc. One might think that the task will never throw, but it can.

However, my suggested change would break the following:

public void SomeMethod()
{
  var myTask = new Task(() => ...);
  myTask.IgnoreExceptions().Start();
}

Internally we've decided to obsolete this extension method as it's too confusing!

user2116722
  • 119
  • 2
  • 6