0

In this sample code, when I call a(), the debugger breaks in properly, and I can inspect all local variables and stack frames. enter image description here Now if I call b(), I get a completely useless "exception was thrown at ..." where the stack is unraveled already: enter image description here

How can I fix this?

  • Can't reproduce. Which VS version, .NET version etc. are you using? – Corey May 27 '22 at 03:56
  • .NET 6.0 fixes this behavior. For 5.0, you could use Tools > Options > Debugging > General, tick "Enable Just My Code". Which makes no sense whatsoever, but bugs don't need to make sense :) – Hans Passant May 27 '22 at 12:47
  • I've only contradicted one of @HansPassant (rep 897,294+) comments [one other time](https://stackoverflow.com/questions/52609592/how-to-pass-booleon-back-from-worker-progresschanged-to-worker-dowork/52611382#52611382). In `Exception Settings` you can check/uncheck the `Break When Thrown` for `[x] System.Exception`. In every version of VS I've used (since V 7 in 2003) this setting determines whether it will or won't break on that line. For the first time ever, the ability to enable or disable it appears to be broken. It _does_ make perfect sense and it's _not_ a bug (Until now. In my opinion :) – IVSoftware May 27 '22 at 13:18
  • For anyone who sees this question @HansPassant solution worked for me –  May 30 '22 at 02:49

1 Answers1

2

I reproduced your issue. Try going to Exception Settings and click one time on the box for Common Language Runtime Exceptions changing from this:

enter image description here

To this:

enter image description here

On my test setup when I turn on all CLR exceptions to Break When Thrown I get the correct breakpoint. If you achieve the same result, the issue is that some exceptions have this disabled by default. They still throw, they just don't break. As an alternative to enabling all of them, you can expand the entry to see exactly which ones are disabled and customize the settings if you choose.

enter image description here

EDIT I also ran and confirmed what Hans just stated in his comment, that this always breaks with a .NET 6 Core console app. So the new issue seems to be that you can uncheck the break when this exception type is thrown in the popup, but that setting gets ignored and it breaks anyway.

enter image description here

IVSoftware
  • 5,732
  • 2
  • 12
  • 23
  • 1
    It works, but not exactly the "true" fix. All this does is make **every** exception get broken in on when it is thrown. What I want is to break in on only exceptions that are unhandled. Hans' comment worked for me. –  May 30 '22 at 02:45
  • I'm glad you're moving forward with Han's answer that's the point for sure. Yes, what I _showed_ was turning on `Break When Thrown` for every exception there is. Mainly, I wanted to draw attention to Exceptions Settings - that expanding it offers precise control over what does/doesn't break. E.g. debugging a Unit Test method that is testing cancellations, I have to turn off `System.Operation.Cancelled` or it stops running. – IVSoftware Jun 01 '22 at 15:33
  • The thing Hans pointed out about .NET Core 6 leaves me with a new concern; Has there really been a fundamental change in the way this has always behaved? I don't really _want_ to write my Unit Tests all over again :( – IVSoftware Jun 01 '22 at 15:34