Visual Studio vs Rider - Debugging Dilema - Reverting back to VS2022?

I can't believe I'm alone in finding the exception debugging experience a total nightmare in Rider.

Having an exception raised in a large project begins my journey of frustration, starting with the 50 entries in the stack trace, 49 of which are not my code, and pointing eventually to a line that refuses to show me the variable values.

Or perhaps I need to look into one of the other 40 threads that are running because I made the mistake of using async functions?

But wait, there's an additional tab if I re-open the exception by clicking on the lightening symbol (which seems to jump and swap places with the breakpoint red-dot when I try to click on it). Well, this is closer to what I want, and is significantly less cluttered, but I still can't see the values in variables because they are mysteriously unavailable.

OK, so I (extremely super reluctantly) boot up an install of VS2022, run the same code, get the same exceptions, and *POW*, there's the error line, with all the variables working, with exception stopped on the appropriate line.

I asked some colleagues with tens of years C# development how their experience was with Rider, and several told me they were back on VS because debugging was so painful.

I've been on Rider since the first Beta, but this process is just killing me, and I've reached breaking point.  I don't want another "Please send us a sample application and a stack trace" from the Rider team, because this happens on every project I work on, on every machine, with factory defaults, and with every option everywhere toggled as a test.

Can I suggest that someone in JetBrains creates a YouTube video showing a REAL debugging session, with async functions, with  exceptions in libraries (not a pointless 'Throw' statement in the source) and demonstrate how it's possible to configure and use it for async heavy applications?

Then, if you can get it to be usable by human developers, make those the defaults!!!


1 comment

OK, copied from another thread I responded to:

OK, well I think I've found the magic combination.

It turns out that enabling "Only break on exceptions thrown from user code" in the Breakpoints dialogue prevents you seeing any contextual information if an exception is raised in an external library.

So that option quite literally means "Only break and show context if you throw an exception in your own source code, or do a core error (such as divide by zero)", and not "Only show me the exception context in the stack trace from my own source upwards" which is the impression the option text gives.

Also, if you don't have "CLR Exception Breakpoints/Any Exception" enabled, it just stops with no context information, and your source lines don't appear in the stack trace at all. Very confusing!

Perhaps we need a 'Set default debugging options' menu command to set the defaults to a usable state for typical debugging?



Please sign in to leave a comment.