How to make Visual Studio on Mac break on error line instead of breaking in the main class?

Viewed 1118

When I'm debugging my project and I encounter a runtime error the debugger stops on the main line instead of the error line.

using AppKit;

namespace Project {
    static class MainClass {
        static void Main(string[] args) {
            NSApplication.Init();
            NSApplication.Main(args); // breaks here
        }
    }
}

Instead of error line:

if (isTrue) {
    button.Title = "Title"; // Object reference not set to an instance of an object
}

Is there a way to change this so it breaks on the line that has the error?

enter image description here

enter image description here enter image description here I tried the Ignore option:

enter image description here

However, it is unchecked the next time around:

enter image description here

2 Answers

This worked for me in Visual Studio for Mac:

  1. Go to the main menu View -> Debug Windows -> Breakpoints

  2. Click the New Exception Catchpoint button

  3. Leave the options pretty much as they are, i.e.:

    a) Breakpoint Action = Pause the program

    b) When to Take Action = When an exception is thrown ("System.Exception"; Include subclasses = true)

  4. Confirm by clicking the Create button

  5. That's it. Start the project (the main menu Run -> Start Debugging or just hit the play button in the toolbar) and enjoy catching the errors

That depends. Certainly the easiest way (if you know you're looking for a particular error) is to enable (check) the corresponding exception in the exceptions window (Debug->Windows->Exception settings->Common Language Exceptions). Since NREs are nothing you would expect at runtime, this works quite ok for these.

What you want is typically the default behavior, if the exception is unhandled and on the main thread. If the exception happens in a task or async method, things truly get a bit ugly, because then the exception is first wrapped to an AggregateException which is later thrown to the main thread when the task is awaited for.

When you get that undesired behavior, do you still have the correct location in the call stack? You might also need to disable "just my code" if the exception happens in a different module.

Related