VS Code has first-class actions for running in Debug and "noDebug" modes. Our current distinction is:

• Run - does not connect the debug adapter to the VM Service
• Debug - does connect the debug adapter to the VM Service

This means in noDebug, anything that uses the VM Service will be unavailable:

• breakpoints
• break on exception
• (expression eval??)
• dart:developer log()
• navigating to files from ToolEvents

This distinction is not clear/obvious, and to confuse things further in the legacy debug adapters we did connect the VM Service in noDebug mode but only for Flutter.

The reason for doing more than just disabling breakpoints/break-on-exception in noDebug mode is that these are trivially toggleable in the UI anyway (users can easily do this, including changing it while the session is running, and VS Code could also just do this by not sending those settings to the debugger when you run if this was the intention).

However, we may have gone too far the other way. For example although we route ToolEvents through the VM Service, it's not obvious that this functionality would be unavailable in Run mode.

Functionality to decide on/verify:

• breakpoints (handled by VS Code since Start without debugging should not register breakpoints microsoft/vscode#129255)
• break on exception (handled by VS Code since Start without debugging should not register breakpoints microsoft/vscode#129255)
• dart:developer debugger() calls
• dart:developer log() calls
• expression evaluation
• hot reload/restart
• ToolEvent navigation
• commands like "toggle repaint rainbow"
• asserts
• logpoints