How to handle exceptions in tasks with a debugger?

I studied this article on MSDN , as well as some questions / answers on SO on this topic, but I canโ€™t understand why the code below does not work (in the example, a console application).

It is expected that the result will establish that an AggregateException indicates that MSDN will contain one internal exception with a hello message. Instead, the hello exception is not handled. This happens when inside the debugger.

If you click continue or run offline, it will work as expected. Is there any way to avoid clicking continue all the time in VS? In the end, everything inside the Try...Catch block is considered processed in a single-threaded programming model. Otherwise, debugging can be a nightmare.

Vb.net

 Sub Main() Try Task.Factory.StartNew(AddressOf TaskThatThrowsException).Wait() Catch ex As AggregateException Console.WriteLine(ex.ToString) 'does not get here until you hit Continue End Try End Sub Private Sub TaskThatThrowsException() Throw New Exception("hello") 'exception was unhandled End Sub 

FROM#

 namespace ConsoleApplication1 { class Program { static void Main(string[] args) { try { Task.Factory.StartNew(TaskThatThrowsException).Wait(); } catch (AggregateException ex) { Console.WriteLine(ex.ToString()); //never gets here } } static void TaskThatThrowsException() { throw new Exception("hello"); //exception was unhandled } } } 

Is there something obvious I'm missing here?

+7
source share
2 answers

The value "Include only my code" affects this. Under Tools-> Options, Debugging-> General-> Include only my code. If you enable it, it will consider an exception that is unhandled if your code does not handle it. Try disabling this feature.

See: http://msdn.microsoft.com/en-us/library/dd997415.aspx

+2
source

This is most likely due to a misunderstanding of what the Visual Studio dialog says.

The exception is "the user is not processed", because there is no user code that catches him (the original Exception ), it is caught by the TPL. So, if you allow the debugger to continue working, or if you run the application without a debugger, you will see the behavior that you expect.

+2
source

All Articles