Repository: Dart-Code/Dart-Code

Issue #4876: Document & Review differences between Run and Debug modes
Created: 2023-12-04T17:13:21Z
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 microsoft/vscode#129255)
break on exception (handled by VS Code since 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

Duplicate issue #4875: Developer logs not showing up on the debug console anymore while running using the 'Run Without Debugging' option
Created: 2023-12-04T16:21:04Z
Describe the bug
Outputs of the log() function from dart:developer import is not showing up at the debug console anymore unless you run the app using "Run > Start Debugging". This was not the case before, I was able to see the logs on my console using "Run > Run Without Debugging" option.
I sometimes need to output long data on my console but this is not seem to be possible using print() since it truncates the text. I also don't want to use debugging mode while developing my application because the app runs too slow and it gets interrupted for every exception.
flutter/flutter#135445
To Reproduce
Steps to reproduce the behavior:

Import dart:developer into your dart code
Log something using log() function
Run the app using "Run > Run Without Debugging"

Expected behavior
Log output to be displayed on debug console.
Please complete the following information:
You can run the Dart: Collect Diagnostic Information command from the VS Code command palette (F1) to easily capture this information or provide it manually.

Operating System and version: macOS Sonoma 14.1.2
VS Code version: 1.84.2
Dart extension version: v3.78.0
Dart/Flutter SDK version: 3.16.2
Target device (if the issue relates to Flutter debugging): iOS Simulator, macOS, Android Emulator, Web

Closing comment (2023-12-04T18:08:59Z): Thanks for the details - This is currently expected behaviour. Running with "Run" does not connect to the VM Service so functionality that requires a VM Service connection is not available. This was always the case for Dart, but the legacy debug adapters did used to connect the debugger even in noDebug mode.
I've opened #4876 to document and review the specifics here. It may be that "connecting the VM Service" is not the best place to draw this line between Run/Debug, but we should review (and document) exactly which functionality should be affected by this.

I also don't want to use debugging mode while developing my application because the app runs too slow and it gets interrupted for every exception.

You can choose whether or not the debugger breaks on exceptions here:

If you untick those options, it will not pause on exceptions. I'm unsure what kind of performance difference you're seeing, but if it's caused by connecting the VM Service then they may appear in Run mode if we connect the debugger. If you can provide some more concrete details on the performance difference you see, we can figure out whether it's caused by something in the debug connection.
I'll close this as a dupe of #4876 because I think any changes should come out of that rather than just reverting this change.