3

As we know in .net 4.5 UnobservedTaskException does not crash an app.

To make it easier for developers to write asynchronous code based on tasks, the .NET Framework 4.5 changes the default exception behavior for unobserved exceptions. Although unobserved exceptions still raise the UnobservedTaskException exception, the process does not terminate by default. Instead, the exception is handled by the runtime after the event is raised, regardless of whether an event handler observes the exception. This behavior can be configured. Starting with the .NET Framework 4.5, you can use the configuration element to revert to the behavior of the .NET Framework 4 and terminate the process:

Ok, assume Microsoft decided to change the experience of multi-thread working with exceptions but why it applied only for tpl then? Why the other parts of multi-thread mechanisms was not changed? Eg, the following code still crash the app

static void Main(string[] args)
{
    ThreadPool.QueueUserWorkItem(state => { throw new Exception(); });
    Console.ReadLine();
}

It's confusing and looks very strange. Anybody know anything about this?

Serg046
  • 1,043
  • 1
  • 13
  • 42
  • 2
    "Why the other parts ... was not changed?" is easy, that would promote bad software. Why the regime for Tasks was lightened is a good question though. – H H Jul 21 '16 at 15:30
  • Agree. But I don't understand why Task logic has been changed. We was able to use TaskScheduler.UnobservedTaskException event to hide and log exceptions if we want... – Serg046 Jul 21 '16 at 15:46
  • 1
    `TaskScheduler.UnobservedTaskException` offers a false sense of security to begin with, since faulted tasks only raise this event if and when they are finalized. It's quite easy for a task to never get finalized (or only at a time when handling the error is no longer interesting), so it's not even guaranteed that a faulted task can actually be observed. At least not crashing has the benefit of being consistent, in that you're guaranteed that *no* unobserved fault will bother you. :-P – Jeroen Mostert Jul 22 '16 at 13:55
  • The TPL is a mechanism to handle async computation but it is NOT connected directly to Threads / ThreadPools etc.., it's an abstraction atop of it to make dev easier - if you choose to use the more primitive objects you should know what your doing... – barakcaf Jul 24 '16 at 12:18
  • @barakcaf, have you read a question? I don't understand why you posted your comment :) – Serg046 Jul 24 '16 at 12:24
  • you ask why microsoft changed only the tpl mechanism, well i've suggested a possible reason... – barakcaf Jul 24 '16 at 12:26
  • Because there's absolutely no reason you should have to observe the result of a task. In many cases, you simply can't. Forcing people to observe complete tasks, would force them to do things like... stores tasks in a list and then monitor the list for completed tasks. That's totally incompatible with a fire-and-forget kind of asynchronous operation. You don't need to necessarily do or handle the completion of an asynchronous operation. – Triynko Oct 22 '20 at 17:35
  • For example, I have a WinForms Control that receives an Operation object that has a Task property representing completion of a data load. When the control is assigned the Operation, it attaches to the Task with a call to ContinueWith on that Task to render the data when the load completes, but that ContinueWith also returns a Task! I don't need that last Task. It becomes a chicken and egg problem. I'd need a task (or thread) to 'wait' on the Task returned by ContinueWith to complete in order to observe it. That's useless. The continuation is all I need, and then it's done. – Triynko Oct 22 '20 at 17:39
  • I mean... I guess instead of calling ContinueWith, I could just call Task.GetAwaiter().OnComplete(Action), which doesn't return a Task. :/ – Triynko Oct 22 '20 at 17:43

0 Answers0