Debugger cannot display callstack for exception thrown from "async" method

[llint]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1

VS Code version: 1.13.1
C# Extension version: 1.10.0

Steps to reproduce

1. Create a new dotnet console project, restore it normally, and have it open under visual studio code, and consent to add C# debugging support for the project inside VSC.

2. Replace the generated Program.cs with the code below

    using System;
    using System.Threading.Tasks;
   
    namespace ExceptionTest
    {
        class Program
        {
            static async Task TestException()
            {
                await Task.Delay(1000);
                throw new Exception(); // the debugger is paused, but no callstack information is available
            }
   
            static void Main(string[] args)
            {
                // throw new Exception(); -- nicely caught by debugger with full callstack
   
                TestException().Wait();
            }
        }
    }
   

3. Make sure "User-Unhandled Exceptions"is ticked, leaving "All Exceptions" unticked

4. Start debugging through the debug menu within VSC

Expected behavior

When debugging under the debugger, the exception thrown from within TestException should pause the debugger, and full stack information should be shown, as well as the file/line information, and local variables, etc..

Actual behavior

When debugging under the debugger, the debugger is paused due to the exception thrown within TestException, but no callstack information can be found through the debugger displays, except that only two threads (on my Mac) are shown, but lacking the stack information for each thread.

[llint]

The seems to be working before I updated to either the latest version of VSC, or the latest version of C# extension.

[gregg-miskelly]

@llint there are actually a bunch of different layers to this.

First, your expected behavior isn't something that is possible. Short summary: exceptions thrown from an async method which returns a Task are not considered 'user unhandled'.

Explanation (if you care why): There is a design flaw, from a tooling perspective (its good in other ways), with System.Task. That flaw is that it is common for callers of an async method to not have signed up to listen for the result of that async method at the time that said async method starts executing asynchronously. This makes it impossible to decide, at the time an exception is thrown from an async method, if any user code will wind up handling that exception.

Next, the 'actual behavior' you are seeing is still clearly very broken. This is due to a couple of different problems with VS Code. The good news is something that the VS Code team fixed recently (microsoft/vscode#27903). This results in a far less confusing behavior in current insiders builds (see screen capture at the end). From there you can evaluate $exception.InnerException.StackTrace to see where the exception is from.

In addition, there two other remaining issues:

• Exception experience in VS Code is somwhat confusing #1007: We currently do NOT display any information about the inner exception in the exception peak window (unlike in Visual Studio). I am hoping we can provide that.
• Debugger cannot display '$exception' for a .NET Core 2.0 app #1593: Things are currently pretty broken for .NET Core 2.0 it seems.

[gregg-miskelly]

I am going to resolve this as 'External' since the primary bugs are with VS Code.

[llint]

Thanks Gregg!