Do not break on exceptions thrown in undebuggable code if caught in undebuggable code

[brianquinlan]

There are several issues where users were confused by the the "Break on all exceptions" option when an exception is thrown in core library code and handled in core library code, e.g.
dart-lang/sdk#52615
dart-lang/sdk#52423

I proposed that, by default, if an exception is thrown in code that is not debuggable and will be caught in code that is not debuggable, then the debugger will not break even if "Break on all exceptions" is enabled.

For example:

part of dart.core

void _foo() {
  throw Exception('foo');
}

void bar() {
  try {
   _foo();
  } on Exception {};
}

Calling bar should not cause the debugger to break on throw Exception('foo'); because the exception is both throw and caught in undebuggable code i.e. it is just an implementation detail of bar.

Another example:

part of dart.core

void _foo() {
  throw Exception('foo');
}

void bar() {
   _foo();
}

// User code:
void main() {
  try {
    bar();
  } on Exception {}
}

Calling bar should cause the debugger to break on throw Exception('foo'); because the exception is caught in debuggable code.

This UX will require VM changes.

[DanTup]

if an exception is thrown in code that is not debuggable

Do we mean based on the setLibraryDebuggable() flag?

This sounds like a great idea to me - although shouldn't it be in the sdk repo instead of here?

[brianquinlan]

if an exception is thrown in code that is not debuggable

Do we mean based on the setLibraryDebuggable() flag?

Yes.

This sounds like a great idea to me - although shouldn't it be in the sdk repo instead of here?

You mean the implementation of this feature? Yes. But I thought that this repo would be better for building consensus that the UX is correct.

[a-siva]

//cc @derekxu16

@brianquinlan should we add a p2 priority to this issue?

[aam]

I proposed that, by default, if an exception is thrown in code that is not debuggable and will be caught in code that is not debuggable, then the debugger will not break even if "Break on all exceptions" is enabled.

I think "all exceptions" (you break on) should continue to mean "all exceptions". It is not a default option, users manually select it for some reason. I think we should introduce another user-facing "all app exceptions" option making it clear that "all exceptions" will get you stopped on all, which include internal dart sdk exceptions.

[brianquinlan]

I think "all exceptions" (you break on) should continue to mean "all exceptions". It is not a default option, users manually select it for some reason. I think we should introduce another user-facing "all app exceptions" option making it clear that "all exceptions" will get you stopped on all, which include internal dart sdk exceptions.

I think that not breaking on exceptions used internally in the SDK is symmetrical with other debugger features like not being able to step into SDK code.

[aam]

I think that not breaking on exceptions used internally in the SDK is symmetrical with other debugger features like not being able to step into SDK code.

The difference I see is that "all exceptions" are explicitly called out in the name of the option: "Break on all exceptions". Other debugging features that are aware of user app code vs core code(stepping, etc) are not configurable, arguably can't confuse users.

[a-siva]

The difference I see is that "all exceptions" are explicitly called out in the name of the option: "Break on all exceptions". Other debugging features that are aware of user app code vs core code(stepping, etc) are not configurable, arguably can't confuse users.

vm_service does allow configuring a library as debuggable ( https://pub.dev/documentation/vm_service/latest/vm_service/VmServiceInterface/setLibraryDebuggable.html)

[DanTup]

In VS Code we allow the user to choose which libraries are debuggable, grouped by:

• "My code" (projects that are open in my workspace)
• "SDK code" (the Dart SDK)
• "Other packages" (Pub packages + Flutter)

The default is "My Code". If you set a breakpoint outside of your workspace (eg. by using Go-to-Definition into the SDK and adding a breakpoint there), you will be prompted to change the settings because otherwise the breakpoints will not be hit. Current stats for those opted-in are approximately:

• My Code: 77%
• My Code + Packages: 12%
• My Code + SDK + Packages: 11%
• My Code + SDK: 1%

So I think users are fairly comfortable with controlling which libraries are debuggable. For me personally, using "My Code" means I want to treat the SDK and packages like a block box. I don't want to debug them, and I presume they are bug free. I am only interested in my own code. As such, I think the proposal here would work well for me - I'm not interested in SDK/packages using exceptions for their own purpose even if I enabled "break on all exceptions" because I'm trying to track down a caught exception in my own code.

If I do want to track down an issue I think is in the SDK, I can switch to debugging inside SDK sources (which allows breakpoints to work there) temporarily while doing so.

We could certainly add a third tickbox for exceptions, but it feels like we're adding two parallel ways to control which sources you're interested in debugging.

[a-siva]

Do devtools and other IDEs like IntelliJ etc. have similar functionality for allowing the user to choose which libraries are debuggable ?

[DanTup]

@stevemessick @kenzieschmoll do you know the answer to the above? Can IntelliJ and DevTools users control which libraries are marked as debuggable (via the setLibraryDebuggable VM Service call)?

(although I'm not sure if it's appropriate for DevTools to try and set these if an IDE might have configured them already)

[stevemessick]

IntelliJ allows configuring some Java classes to be ignored during debugging, but not at the library level. I'm not aware of any way to ignore Dart classes. There is nothing in the settings panel of the Dart or Flutter plugins to do it. I can't recall anything in the debugger, other than "Step Over".

[DanTup]

Does this mean in IntelliJ a user can't control whether "Step Into" would go into SDK sources or not?

If not, and if we want to support this there - maybe the better option is to add support for it (or maybe in future it could use DAP?).

Using the existing debuggable flag does feel like a natural way to solve this issue to me - we can "group" these libraries from the IDE in ways I suspect the runtime cannot (for example, we let the user choose whether packages that aren't part of their workspace are debuggable - so they can toggle Pub/path dependencies separately from the SDK). If we added additional tickboxes alongside "All exceptions" and "Uncaught exceptions" I'm not sure if we could support that (at least not without having another per-library flag that the IDE/DAP toggles like it does with setLibraryDebuggable)?

[escamoteur]

Please see also Dart-Code/Dart-Code#4600
the idea of flutter_commands is that they try to catch all exceptions but for debug we rethrow them immediately to more easily find their real source. In the past 'break on all exceptions` was enough for that but since some releases this doesn't work anymore because of the problems already reported above.