Skip to content

DataBreakpointEvent? #30

Open
Open

Description

I might be missing something here, but the Breakpoint type is for »Information about a Breakpoint created in setBreakpoints or setFunctionBreakpoints« while DataBreakpoint is for »Properties of a data breakpoint passed to the setDataBreakpoints request« and the BreakpointEvent is only for Breakpoint breakpoints. So it does not make sense to use BreakpointEvent for a change in a DataBreakpoint.

There is no DataBreakpointEvent. Is that an accidental omission?

I might want to create a data breakpoint based on a launch.json configuration option and inform vscode about it, so users can disable the breakpoint if they so choose (or for that matter, users might configure data breakpoints through the debug console instead of the vscode ui, and then I might also want to surface such breakpoints through vscode anyways).

Activity

  1. yannickowow commented on Nov 28, 2020

    @yannickowow

    Hi,
    I am facing the same thing here.
    Same issue appears as well between Breakpoint and FunctionBreakpoint, so we can't distinguish a new Breakpoint when sending this event. I guess it'll be similar with InstructionBreakpoint.

  2. jreineckearm commented on Aug 30, 2023

    @jreineckearm

    Hi, we are hitting a similar problem for a debugger that offers console commands to manage breakpoints, including data breakpoints. For data breakpoints we cannot make the UI aware of changes driven by the console.

  3. samisalreadytaken commented on Jan 20, 2025

    @samisalreadytaken
    Contributor

    There is SourceBreakpoint, FunctionBreakpoint, InstructionBreakpoint and DataBreakpoint for their respective breakpoint representation in requests, Breakpoint exists for responses and for BreakpointEvent as a generic interface for all kinds of breakpoints.

    As it stands, Breakpoint only includes information for SourceBreakpoint (source, line, column etc.). This arbitrary limitation could be resolved by extending Breakpoint to include breakpoint type and function/instruction/data breakpoint details. Specifying that the lack of type represents a source breakpoint would maintain backwards compatibility.

    This same issue was brought up in #406 as well where Connor Peet (@connor4312) closed it for lack of interest, probably missing this 5 year old issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature-requestRequest for new features or functionality

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions