Support per-library exception pause mode

[shyndman]

Original requested at Dart-Code/Dart-Code#2187

@shyndman wrote

There are lots of cases where exceptions are used as flow control in external libraries, which limits the value of breaking on "All Exceptions" because of all the false positives.

It would be really nice to limit to only breaking on all exceptions that occur in code under my control. Feels like it could be a nice complement to the new debug scoping button (the one that reads "Debug my code + packages + SDK").

@DanTup wrote

This is not currently possible from the VMs APIs - and it may be tricky to implement. The VM doesn't have a concept of "my code", it just knows which libraries are debuggable/not (the VS Code extension makes the decision about which libraries to mark as debuggable based on the settings). I think implementing it would require the VM to support setExceptionPauseMode per-library (instead of once globally). Could you open the request at https://github.com/dart-lang/sdk and should it be implemented in the VM, we can update the extension here to use it. Thanks!

[a-siva]

@DanTup I am not sure I understand why you think the VM service API has to support setExceptionPauseMode per-library for this to work, the client tools can do this kind of filtering by resuming execution when the exception is not from the desired library.

[DanTup]

@a-siva I don't think the editor is able to tell whether an exception will be handled or not. This is normally done in the VM be looking up the stack for try blocks. It would also be quite slow pausing/resuming via the client (and need implementing in each client).

I think it's very similar to setLibraryDebuggable and that's implemented in the VM, not handled by the clients.

[a-siva]

The VM already filters out the exception is handled or not part so the client tool does not have to decide that. The original request talks about breaking on "all exceptions" which I presume includes handled ones too.

There are many design points to consider here

• complicating the code in the VM with all possible scenarios, I would like for the implementation in the VM for the service protocol to be compact with the essential features needed for debugging
• Additional features and filters could be abstracted out in the vmservice package (so it doesn't need implementation in each client)
• All of these require user interactions and I would actually like to see how perceptible the slowness is before claiming additional service requests implies unacceptable slowness.

[DanTup]

@a-siva the request here is to be able to have on "all exceptions" for some libraries (for ex. the users own packages) and "unhandled exceptions" for others (for ex. the SDK or other pub packages). Does the VM include info with exceptions to say whether they will be handled or not?

Additional features and filters could be abstracted out in the vmservice package

It's not clear if this is in the VM or you mean the Dart client library. If the latter, I think that would only help for Dart implementations (VS Code's debug client is TypeScript, and I think IntelliJ's may be in Java (@devoncarew?)).

I would actually like to see how perceptible the slowness is before claiming additional service requests implies unacceptable slowness

Sure - I didn't mean to suggest it would be unacceptable, and performance was a minor concern. We do do this for conditional breakpoints though, and the slowdown can be noticable when it triggers a lot (for ex. inside loops/map()s etc.)

[DanTup]

(FWIW, I think it's reasonable to try to gauge the level of demand for such a feature before implementing anything, but here seems like a better place to collect 👍's since the feature is editor-agnostic)