vscode: VS Code doesn't display error response from invalid exception filter conditions
Issue Type: Bug
- Configure an exception filter with an invalid condition. In my case, I am using an experimental version of the C# debugger, and I used the bogus coniditon of ‘==Bogus’
- Start debugging
Expected: VS Code should somehow tell me that I entered an invalid exception filter by displaying the text from the error response as the DAP spec indicates. My suggestion would be a warning icon next to the exception filters and display the error message as a notification.
Actual: The error response isn’t displayed anywhere.
Here is a partial protocol trace:
-> {"command":"setExceptionBreakpoints","arguments":{"filters":[],"filterOptions":[{"filterId":"all","condition":"==Bogus"},{"filterId":"user-unhandled"}]},"type":"request","seq":5}
<- {"seq":10,"type":"response","request_seq":5,"success":false,"command":"setExceptionBreakpoints","message":"Syntax error in condition for 'All Exceptions'. Unexpected character near column 0 (character '=')."}
VS Code version: Code - Insiders 1.54.0-insider (3290f9a73ba6fc3b1063ea32476067434ee91b1d, 2021-02-26T05:13:29.656Z) OS version: Windows_NT x64 10.0.19042
System Info
| Item | Value |
|---|---|
| CPUs | Intel® Core™ i9-9880H CPU @ 2.30GHz (16 x 2304) |
| GPU Status | 2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: enabled rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled |
| Load (avg) | undefined |
| Memory (System) | 31.79GB (9.60GB free) |
| Process Argv | –crash-reporter-id 8dd46428-3c33-429b-aec8-0a1119b2424f |
| Screen Reader | no |
| VM | 0% |
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 25 (25 by maintainers)
Commits related to this issue
- DAP: setExceptionBreakpoint optionally returns breakpoint array; related to #117789 — committed to microsoft/vscode by weinand 3 years ago
Thanks for the discussion and your input!
I’ve tried to produce a summary and proposal:
There is a desire to treat all breakpoints the same. Today Exception breakpoints are different because they don’t have an ID since there is no way to return the ID from the corresponding
SetExceptionBreakpointsrequest.One area where this difference between breakpoints hurts a lot, is with error reporting: neither is it possible to return a “failed verification” message from
SetExceptionBreakpoints, nor is it possible to send out breakpoint exceptions that contain the error message (because of the lack of an ID).IMO the cleanest approach would be to align
SetExceptionBreakpointswithSetBreakpointsand allow to optionally return an array ofBreakpoints. These breakpoints can be used to return an ID (so that breakpoint events can be sent), or the error message can be directly returned via theverifiedandmessageproperties.I’d prefer the latter because I think that syntax errors in the condition are something that should be returned synchronously rather than as a async event.
@gregg-miskelly @connor4312 @isidorn what do you think?
I’ve created https://github.com/microsoft/debug-adapter-protocol/issues/184 for the required DAP changes.
Since that work will happen in April, I’ve changed the milestone for this issue too.