Jump back to the line of exception occurred during debugging

HI,

I know during debugging, there are options like "run to cursor", "skip to cursor" and "run to cursor non-stop" which allow us to replay some part of code, but this is only valid when no exception occurred. I wondering if there is a way to let me jump back to the line before the exception occur ? The purpose of this is to quickly location the bug location rather than step through the code line by line.

 

Cheers

0
10 comments

Jason Sobell Agreed, I hope someone from Rider team can actually answer this. The exception didn't stop at the correct line is painful, basically force you to debug your code line by line until the exception occur, when it occur, you have to stop and return the application again because cant reply the exception with the current frame. 

0

I've posted this as a support request.

Here's a video of debugging a tiny application with an exception in an external library: https://screenrec.com/share/eahKm2YoDy 

It seems really bizarre to me. Surely there can't be only the two of us in here experiencing this?

0

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?

I and several other people have struggled with this for a long time, suggesting that it's probably unintuitive rather than that we're all incompetent :)

0

Hi Jason Sobell

Thank you for the feedback. Did I understand correctly? that you're looking for several presets for different debug scenarios? While there are a few methods to introduce feature requests, I think your best choice here would be to use our tracker here and submit a request. On the tracker, others can see your request and add their vote if they find such a tool would be useful, which helps our team to understand better which features/tools our users are eager for. I believe this can help give the best visibility for your request.

0

Alexandra Guk Do you guys have documentation or blog to explain what is the difference between CLR exception breakpoints vs Exception breakpoints (rider 2022.1.1 version). It really hard to tell what is Exception breakpoints does, no matter if i set it to "when caught" or "when thrown", does not make any difference at all. Also for the CLR exception, how to use it properly ?

0

Hi Jason Wu! Have you seen this part of the manual? 

Also, occasionally I missed your first main question about step back in the debugger. It is not possible in Rider at the moment, but we have the following feature request for this. Feel free to upvote! 

 

0

Jason Wu The difference between CLR exception breakpoints vs Exception breakpoints is that the former are for .Net and the latter are for C++. When thrown/when caught is obvious but it just doesn't apply to .Net so that's confusing. https://www.jetbrains.com/help/rider/Breakpoints_dialog_Rider.html#549c8d95

2

Vincent Goossens If that is the case, should rename it to c++ exception breakpoints to avoid confusion. But anyway, thanks for the link. Cheers

0

Hi Vincent Goossens Jason Wu

Indeed, the naming there is slightly confusing. We have the following feature request for improving it. Feel free to vote! 

0

Please sign in to leave a comment.