1

I have a code like this:

private async Task<string> GetToken()
{
    try
    {
        response = await nugetPackage.SomeMethod();
        int x = 5;
        x++;
    }
    catch (Exception)
    {
        throw;
    }

    return response.Token;
}

When I try to debug this process, the breakpoint hits the following line:

response = await nugetPackage.SomeMethod();

but it just vanishes beyond that point, i.e., nothing happens on pressing f10. It never reaches

int x = 5;

There is a breakpoint in the catch statement as well which is not being hit either.

The GetToken method is called thus:

var rawToken = await GetToken();

I thought await meant that the main thread would not be blocked so the breakpoint should have hit the next line? What could be the potential explanation for this?

Paagalpan
  • 1,261
  • 2
  • 16
  • 25
  • 2
    F5 is continue and unless you also have a breakpoint on int x=5, the debugger will not stop. Try F10 to step over – spectacularbob Jul 11 '19 at 17:07
  • I had a breakpoint there as well. Let me edit the question. F10 doesnt work either. – Paagalpan Jul 11 '19 at 17:09
  • 1
    If you have multiple things calling this method (like from a loop as example), you can likely be in a different context hitting the original breakpoint PRIOR to your original context hitting the second breakpoint – Kritner Jul 11 '19 at 17:23
  • But even if that were the case, the second breakpoint should be eventually hit at some point? – Paagalpan Jul 11 '19 at 17:28
  • Is this code inside a task? – Reinstate Monica Cellio Jul 11 '19 at 17:30
  • Your understanding of await is very wrong, and so you will continue to be confused until it is correct. The await *asynchronously waits*; the main thread becomes unblocked because *control returns to the caller until the task is complete*. – Eric Lippert Jul 11 '19 at 17:36
  • Your belief about what await does is the *exact opposite* of what it really does. If your intention is to keep running code after the task is fired off, *do not await the task*. An await introduces a *wait*, that's why it's called *await*. It's just an asynchronous wait rather than a synchronous wait. You should read up on this feature and understand it before you use it further. – Eric Lippert Jul 11 '19 at 17:37
  • @Archer not sure what you mean by if its inside a task. But it is an async method. I just updated the question to reflect this. – Paagalpan Jul 11 '19 at 17:39
  • @EricLippert Ah ok. So if I understand you correctly, what might be happening is that the nugetPackage.SomeMethod() might be stuck (in a deadlock or infinite loop) and thus we end up keep waiting and thats why the next line is never reached? – Paagalpan Jul 11 '19 at 17:45
  • Remember, await is about managing *latency*. There is some latency between when the task begins and when it ends. Await means "main thread, find something else productive to do while we are waiting for this high-latency operation to complete". If it never completes, you will wait forever. If it completes with an exception, then eventually you'll resume your workflow and the exception will be thrown. If it completes normally, then your workflow will eventually resume. Which situation you're in, I have no way of knowing. – Eric Lippert Jul 11 '19 at 17:50
  • But you need to understand that await means *this workflow cannot continue until this task is complete*. If your workflow is not continuing, then the task is not complete, and that's the correct behaviour. The main thread will attempt to find *another* workflow that *can* continue, thereby making more efficient use of the thread. If that's not your intended behaviour, don't use await! – Eric Lippert Jul 11 '19 at 17:51
  • Have a look at this... https://stackoverflow.com/questions/7340309/throw-exception-inside-a-task-await-vs-wait – Reinstate Monica Cellio Jul 11 '19 at 18:10
  • 1
    As a more concrete example of trying to find another workflow during an await: Suppose you are responding to a button press on the UI thread of a WinForms application: Then, awaiting would cause the UI thread to pull the next message off of the message pump and process that. Take special note that all of this (both the previous message and the new message) is being processed by the same thread (i.e., the UI thread). Synchronously blocking, would cause the UI thread to block preventing further messages from being processed. This is a bad experience: the app will be frozen. – Brian Jul 11 '19 at 18:53
  • @EricLippert Thanks for the explanation. Would it be safe to say that because the task nugetPackage.SomeMethod(); was never complete, thats the only reason none of the other breakpoints in the method following this line were hit. Or could there be any other explanation? – Paagalpan Jul 11 '19 at 18:53
  • 1
    That is certainly the most likely explanation. – Eric Lippert Jul 11 '19 at 19:00

1 Answers1

-3

F5 is "continue" in Visual Studio, meaning it will continue the program until it hits another breakpoint. If you want to continue line by line after the break point, either use F10, or the "Step Over" button to the right of continue on the top bar (it looks like an arrow going over a blue circle). There are also tools for "Step Into" and "Step Out", which show you the method being called in a line, or what line called the method you are in, respectively.

jmgwynn
  • 5
  • 3