Rider debugger breaks on unhandled exception

Unity Engine
,
1

When attaching the Rider (2021.1.3) debugger to unity 2021.2.0b2 the debugger breaks on an unhandled exceptions very often.
Using same version for rider and same settings I do not experience the same thing with unity 2021.1.

I am unable to break on the exception using Visual Studio.

While testing the beta build last week i have memories of breaking on other exceptions but I am unable to reproduce that now…

2

This has been like this forever, and probably won’t be fixed.

When Unity’s UI was made, the way that “stop drawing immediately” was implemented was “throw a specific exception that will be caught and suppressed at the top of the drawing stack”.

See Unity - Scripting API: GUIUtility.ExitGUI

Now this is a bad idea, because now attaching a debugger hits this intended exception all the time. Don’t use exceptions to organize control flow, children! But since all of Unity’s editor code is dependent on this, then it can’t get fixed on Unity’s side without a massive undertaking that’s unlikely-

On Rider’s side, what you have to do to work around this is to turn off “Any Exception” in the breakpoint list, and instead manually add all the likely common exceptions:

7301983--884347--upload_2021-7-6_14-46-18.png

Which is annoying. Rider could make this better by letting “Any Exception” have a filter for “except these specific exceptions”. “Any Exception” also has a “Only in my code” toggle, but I don’t think it’s got a good understanding of what “my code” is in the context of Unity.

4 Likes
3

I have already tried this and it still breaks.
Yes it is true that if I enable “Any Exception” it breaks in Unity 2021.1 the same way.
But even though i disable all exception breakpoints, is still breaks in Unity 2021.2.0.

7302766--884491--upload_2021-7-6_18-10-28.png
7302766--884491--upload_2021-7-6_18-10-28.png1412Ă—567 38.8 KB

(I also get this exception occasionally: Imgur: The magic of the Internet with all exceptions disabled)

This really feels like a Rider bug but the only varying factor is which version of Unity is used?

I have tried the “Only in my code” toggle as well. And if I disable that toggle and enable all exceptions I get three thrown exceptions, the two first has an option to Mute so I assume these are classified as “My code”, but the last one always breaks even though all exception break points are disabled (using Unity 2021.2)
(The exceptions: Imgur: The magic of the Internet)

2 Likes
4

That seems like a Rider bug! Running the debugger with no breakpoints shouldn’t break.

1 Like
5

Strictly speaking, this isn’t a Rider bug, but we could definitely do something to provide a nicer experience for Unity.

The exception is thrown in managed code, but intended to be caught in native code. As such, there is no managed code to handle the exception, and so Mono and Rider treat it as an unhandled exception, and Rider will break in the debugger. In the normal .net world, an unhandled exception is a bad thing, which has a high chance of crashing your app, so it’s a good thing that the debugger stops and lets you know. Of course, Unity isn’t a normal .net app, but hosts Mono and calls your methods directly - there is no way for Rider to know that this is happening, and no way to know if an exception will be handled by the native code. So Rider is doing the best it can with the information it’s got, but in this particular scenario, it’s undesired behaviour.

You can disable this behaviour in the Preferences | Build, Execution, Deployment | Debugger settings page, with the “break on unhandled exceptions” checkbox. This has implications, though. It means that Rider will no longer break on ANY unhandled exception, for any project you open, not just this Unity project, and it might be very helpful to get these unhandled exception notifications.

We’ll improve this situation for the next Rider release (we’re just finalising Rider 2021.2, so we don’t have time to get it in there, so it’s likely to be 2021.3), so Rider will know to ignore unhandled ExitGuiExceptions. The checkbox is there as a workaround for now. (The issue to track is RIDER-64944).

Interestingly, I think Unity’s behaviour has changed recently. As part of Rider 2021.2, I’ve added support to ignore unhandled exceptions for IL2CPP players, to mimic the behaviour of the editor. I have a project with unhandled exceptions that would break when debugging in IL2CPP, but not in the editor - Mono wasn’t reporting unhandled exceptions to us. I’ll try to find out what’s changed.

9 Likes
6

Just to follow up, this is all down to Unity 2021.2 upgrading the Mono runtime. The previous version would not report unhandled exceptions to the attached debugger, so you never saw ExitGUIException. The new version does report unhandled exceptions, for user code as well as Unity/3rd party code. The change in behaviour was not intentional, but it’s not yet clear what will happen going forward. I’ve just merged a change into Rider so that for Rider 2021.2 (starting with EAP7) we’ll ignore unhandled ExitGUIException. This should make debugging the editor less noisy.

You can continue to suppress all unhandled exceptions by unchecking the “break on unhandled exception” option in settings, and you can use the exception breakpoints to stop whenever a specific exception type is thrown, including ExitGUIException, if you wish. See also JetBrains/resharper-unity#2119.

6 Likes
7

Nice!

Thanks for all the great work you do on on the Rider/Unity integration. It makes the my day-to-day programming life a lot better.

8

You can disable this behaviour in the Preferences | Build, Execution, Deployment | Debugger settings page, with the “break on unhandled exceptions” checkbox.

Thanks!

2 Likes
9

Thank you for this explanation, I recently went to Unity 2022 with an older Rider version (2020.3) and ran into this. Will upgrade Rider at some point but in the moment it’s good to have a fix.

1 Like