Why doesn't my process terminate when Task has unhandled exception?

Question

I am building a Windows Service with .NET 4.0.

I have various unhandled exceptions thrown in Tasks, but they do not terminate my process as the MSDN documentation states (Parallel Tasks - see Unobserved Task Exceptions).

"If you don't give a faulted task the opportunity to propagate its exceptions (for example, by calling the Wait method), the runtime will escalate the task's unobserved exceptions according to the current .NET exception policy when the task is garbage-collected."

It behaves like this even when I use the most simple invokation of a task:

Task.Factory.StartNew(() => { throw new Exception(); } 

The service keeps on running fine when that is called.

According to the docs, the finalizer of the Task will rethrow the exception once the Task is GC'd but this does not appear to happen. MSDN states repeatedly that normal ".NET exception policy" results in process termination.

Why doesn't this terminate my app? The only thing I can think is there is somehow a reference to the task held somewhere (is it the lambda??)

Answer 1

From Essential C# 4.0, page 715, the following might help you out:

The unhandled exception during the Task's execution will be suppressed until a call to one of the task completion members: Wait(), Result,Task.WaitAll(), or Task.WaitAny(). Each ot these members will throw any unhandled exceptions that occurred within the task's execution.

Quite a few ways of handling exceptions are available. Have a look at MSDN here.

In answer to your comment, another quote from the same book explains why some exceptions are not propagated:

Although relatively rare, one of the exceptions for the general rule (of bubbling up) happens to be on Task. [..] Any Task-based exceptions thrown from the finalization queue during application exit will go suppressed. The behavior is set this way because frequently the effor to handle such an exception it too complex [...]

To overcome this, one way to do this elegantly is to create an exception handler task and to use ContinueWith to follow up after your task runs. You can then use parentTask.IsFaulted and gracefully crash, even in the event the exception is thrown in the finalization queue during application exit.

Tip: use the the flag OnlyOnFaulted to have this task run only when an exception occurs.

Answer 2

.NET 4.5 made some changes as to how UnobservedExceptions are handled

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.

This behavior can be configured though, so you can revert back to .Net 4.0 behavior by enabling ThrowUnobservedTaskExceptions like so:

<configuration> 
    <runtime> 
        <ThrowUnobservedTaskExceptions enabled="true"/> 
    </runtime>
</configuration>

It's recommended library developers enable this when testing to ensure they don't have any UnobservedExceptions being thrown. Otherwise library consumers with this setting enabled might see their programs crashing.

Answer 3

As suggested by @Hans and @CodeInChaos I found the only way to rethrow the unhandled exception (thus killing the process) is to force the Finalizer to run (Note: Make sure you dont do this in the ContinueWith()!):

GC.Collect(); 
GC.WaitForPendingFinalizers();

In my particular circumstances the Task was not garbage collected because the flow of the program depended on the Task being succesful. Without the flow continuing my app would not do anything to cause a GC (allocate objects etc).

What is interesting is that even doing a GC.Collect() is not enough. The Task finalizer still did not run. The GC.WaitForPendingFinalizers() had to be called explicitly. (I suspect I do not understand subtleties around Finalization).

To summarize: Dont expect a TPL Task's unobserved exception behaviour to be similar to other threading mechanisms unhandled exception behaviour (e.g. QueueUserWorkItem). In most practical situations you need to explicity check for Exceptions from Tasks: you cannot rely on unobserved exceptions being brought to your attention in the way they would with a QUWI or similar because you will only see them thrown from the Finalizer which is totally unpredictable.

Edit: See my other answer concerning .NET 4.5

Answer 4

According to this nice blog post if you want to crash your app as soon as you have unhandled exception in your task then you can continue your task something like below:

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

Answer 5

You may create it with TaskCreationOptions.AttachedToParent. According to Nested Tasks and Child Tasks (MSDN), Exceptions are then propagated to your thread. I do not know, however, whether this is elegant or not.

Microsoft does not recommend this "in most cases". Somebody else might know in what case this may be sensible. From the same article:

You can use attached child tasks to create tightly-synchronized graphs of asynchronous operations. However, in most scenarios, we recommend that you use nested tasks because the relationships with other tasks are less complex. That is why tasks created inside other tasks are nested by default, and you must explicitly specify the AttachedToParent option to create a child task.

Cheers, Matthias