Package org.eclipse.lsp4j.debug.services

Interface IDebugProtocolServer

    • Field Detail

      • SCHEMA_VERSION

        static final java.lang.String SCHEMA_VERSION
        Version of Debug Protocol
        See Also:
        Constant Field Values

    • Method Detail

      • cancel

        default java.util.concurrent.CompletableFuture<java.lang.Void> cancel​(CancelArguments args)
        The 'cancel' request is used by the client in two situations:
        • to indicate that it is no longer interested in the result produced by a specific request issued earlier
        • to cancel a progress sequence.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsCancelRequest() is true.

        This request has a hint characteristic: a debug adapter can only be expected to make a 'best effort' in honoring this request but there are no guarantees.

        The 'cancel' request may return an error if it could not cancel an operation but a client should refrain from presenting this error to end users.

        The request that got cancelled still needs to send a response back. This can either be a normal result ('success' attribute true) or an error response ('success' attribute false and the 'message' set to 'cancelled').

        Returning partial results from a cancelled request is possible but please note that a client has no generic way for detecting that a response is partial or not.

        The progress that got cancelled still needs to send a 'progressEnd' event back.

        A client should not assume that progress just got cancelled after sending the 'cancel' request.

      • initialize

        default java.util.concurrent.CompletableFuture<Capabilities> initialize​(InitializeRequestArguments args)
        The 'initialize' request is sent as the first request from the client to the debug adapter in order to configure it with client capabilities and to retrieve capabilities from the debug adapter.

        Until the debug adapter has responded with an 'initialize' response, the client must not send any additional requests or events to the debug adapter.

        In addition the debug adapter is not allowed to send any requests or events to the client until it has responded with an 'initialize' response.

        The 'initialize' request may only be sent once.

      • configurationDone

        default java.util.concurrent.CompletableFuture<java.lang.Void> configurationDone​(ConfigurationDoneArguments args)
        This request indicates that the client has finished initialization of the debug adapter.

        So it is the last request in the sequence of configuration requests (which was started by the 'initialized' event).

        Clients should only call this request if the corresponding capability Capabilities.getSupportsConfigurationDoneRequest() is true.

      • launch

        default java.util.concurrent.CompletableFuture<java.lang.Void> launch​(java.util.Map<java.lang.String,​java.lang.Object> args)
        This launch request is sent from the client to the debug adapter to start the debuggee with or without debugging (if 'noDebug' is true).

        Since launching is debugger/runtime specific, the arguments for this request are not part of this specification.

      • attach

        default java.util.concurrent.CompletableFuture<java.lang.Void> attach​(java.util.Map<java.lang.String,​java.lang.Object> args)
        The attach request is sent from the client to the debug adapter to attach to a debuggee that is already running.

        Since attaching is debugger/runtime specific, the arguments for this request are not part of this specification.

      • restart

        default java.util.concurrent.CompletableFuture<java.lang.Void> restart​(RestartArguments args)
        Restarts a debug session. Clients should only call this request if the corresponding capability Capabilities.getSupportsRestartRequest() is true.

        If the capability is missing or has the value false, a typical client emulates 'restart' by terminating the debug adapter first and then launching it anew.

      • disconnect

        default java.util.concurrent.CompletableFuture<java.lang.Void> disconnect​(DisconnectArguments args)
        The 'disconnect' request asks the debug adapter to disconnect from the debuggee (thus ending the debug session) and then to shut down itself (the debug adapter).

        In addition, the debug adapter must terminate the debuggee if it was started with the 'launch' request. If an 'attach' request was used to connect to the debuggee, then the debug adapter must not terminate the debuggee.

        This implicit behavior of when to terminate the debuggee can be overridden with the 'terminateDebuggee' argument (which is only supported by a debug adapter if the corresponding capability Capabilities.getSupportTerminateDebuggee() is true).

      • terminate

        default java.util.concurrent.CompletableFuture<java.lang.Void> terminate​(TerminateArguments args)
        The 'terminate' request is sent from the client to the debug adapter in order to shut down the debuggee gracefully. Clients should only call this request if the corresponding capability Capabilities.getSupportsTerminateRequest() is true.

        Typically a debug adapter implements 'terminate' by sending a software signal which the debuggee intercepts in order to clean things up properly before terminating itself.

        Please note that this request does not directly affect the state of the debug session: if the debuggee decides to veto the graceful shutdown for any reason by not terminating itself, then the debug session just continues.

        Clients can surface the 'terminate' request as an explicit command or they can integrate it into a two stage Stop command that first sends 'terminate' to request a graceful shutdown, and if that fails uses 'disconnect' for a forceful shutdown.

      • setBreakpoints

        default java.util.concurrent.CompletableFuture<SetBreakpointsResponse> setBreakpoints​(SetBreakpointsArguments args)
        Sets multiple breakpoints for a single source and clears all previous breakpoints in that source.

        To clear all breakpoint for a source, specify an empty array.

        When a breakpoint is hit, a 'stopped' event (with reason 'breakpoint') is generated.

      • setFunctionBreakpoints

        default java.util.concurrent.CompletableFuture<SetFunctionBreakpointsResponse> setFunctionBreakpoints​(SetFunctionBreakpointsArguments args)
        Replaces all existing function breakpoints with new function breakpoints.

        To clear all function breakpoints, specify an empty array.

        When a function breakpoint is hit, a 'stopped' event (with reason 'function breakpoint') is generated.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsFunctionBreakpoints() is true.

      • setExceptionBreakpoints

        default java.util.concurrent.CompletableFuture<SetExceptionBreakpointsResponse> setExceptionBreakpoints​(SetExceptionBreakpointsArguments args)
        The request configures the debugger's response to thrown exceptions. Each of the `filters`, `filterOptions`, and `exceptionOptions` in the request are independent configurations to a debug adapter indicating a kind of exception to catch. An exception thrown in a program should result in a `stopped` event from the debug adapter (with reason `exception`) if any of the configured filters match.

        Clients should only call this request if the corresponding capability Capabilities.getExceptionBreakpointFilters() returns one or more filters.

      • setDataBreakpoints

        default java.util.concurrent.CompletableFuture<SetDataBreakpointsResponse> setDataBreakpoints​(SetDataBreakpointsArguments args)
        Replaces all existing data breakpoints with new data breakpoints.

        To clear all data breakpoints, specify an empty array.

        When a data breakpoint is hit, a 'stopped' event (with reason 'data breakpoint') is generated.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsDataBreakpoints() is true.

      • setInstructionBreakpoints

        default java.util.concurrent.CompletableFuture<SetInstructionBreakpointsResponse> setInstructionBreakpoints​(SetInstructionBreakpointsArguments args)
        Replaces all existing instruction breakpoints. Typically, instruction breakpoints would be set from a disassembly window.

        To clear all instruction breakpoints, specify an empty array.

        When an instruction breakpoint is hit, a 'stopped' event (with reason 'instruction breakpoint') is generated.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsInstructionBreakpoints() is true.

      • continue_

        default java.util.concurrent.CompletableFuture<ContinueResponse> continue_​(ContinueArguments args)
        The request resumes execution of all threads. If the debug adapter supports single thread execution (see capability Capabilities.getSupportsSingleThreadExecutionRequests()), setting the 'singleThread' argument to true resumes only the specified thread. If not all threads were resumed, the 'allThreadsContinued' attribute of the response should be set to false.

      • next

        default java.util.concurrent.CompletableFuture<java.lang.Void> next​(NextArguments args)
        The request executes one step (in the given granularity) for the specified thread and allows all other threads to run freely by resuming them.

        If the debug adapter supports single thread execution (see capability Capabilities.getSupportsSingleThreadExecutionRequests()), setting the 'singleThread' argument to true prevents other suspended threads from resuming.

        The debug adapter first sends the response and then a 'stopped' event (with reason 'step') after the step has completed.

      • stepIn

        default java.util.concurrent.CompletableFuture<java.lang.Void> stepIn​(StepInArguments args)
        The request resumes the given thread to step into a function/method and allows all other threads to run freely by resuming them.

        If the debug adapter supports single thread execution (see capability Capabilities.getSupportsSingleThreadExecutionRequests()), setting the 'singleThread' argument to true prevents other suspended threads from resuming.

        If the request cannot step into a target, 'stepIn' behaves like the 'next' request.

        The debug adapter first sends the response and then a 'stopped' event (with reason 'step') after the step has completed.

        If there are multiple function/method calls (or other targets) on the source line, the argument 'targetId' can be used to control into which target the 'stepIn' should occur.

        The list of possible targets for a given source line can be retrieved via the 'stepInTargets' request.

      • stepOut

        default java.util.concurrent.CompletableFuture<java.lang.Void> stepOut​(StepOutArguments args)
        The request resumes the given thread to step out (return) from a function/method and allows all other threads to run freely by resuming them.

        If the debug adapter supports single thread execution (see capability Capabilities.getSupportsSingleThreadExecutionRequests()), setting the 'singleThread' argument to true prevents other suspended threads from resuming.

        The debug adapter first sends the response and then a 'stopped' event (with reason 'step') after the step has completed.

      • stepBack

        default java.util.concurrent.CompletableFuture<java.lang.Void> stepBack​(StepBackArguments args)
        The request executes one backward step (in the given granularity) for the specified thread and allows all other threads to run backward freely by resuming them.

        If the debug adapter supports single thread execution (see capability Capabilities.getSupportsSingleThreadExecutionRequests()), setting the 'singleThread' argument to true prevents other suspended threads from resuming.

        The debug adapter first sends the response and then a 'stopped' event (with reason 'step') after the step has completed.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsStepBack() is true.

      • reverseContinue

        default java.util.concurrent.CompletableFuture<java.lang.Void> reverseContinue​(ReverseContinueArguments args)
        The request resumes backward execution of all threads. If the debug adapter supports single thread execution (see capability Capabilities.getSupportsSingleThreadExecutionRequests()), setting the 'singleThread' argument to true resumes only the specified thread. If not all threads were resumed, the 'allThreadsContinued' attribute of the response should be set to false.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsStepBack() is true.

      • restartFrame

        default java.util.concurrent.CompletableFuture<java.lang.Void> restartFrame​(RestartFrameArguments args)
        The request restarts execution of the specified stack frame.

        The debug adapter first sends the response and then a `stopped` event (with reason `restart`) after the restart has completed.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsRestartFrame() is true.

      • goto_

        default java.util.concurrent.CompletableFuture<java.lang.Void> goto_​(GotoArguments args)
        The request sets the location where the debuggee will continue to run.

        This makes it possible to skip the execution of code or to execute code again.

        The code between the current location and the goto target is not executed but skipped.

        The debug adapter first sends the response and then a 'stopped' event with reason 'goto'.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsGotoTargetsRequest() is true (because only then goto targets exist that can be passed as arguments).

      • pause

        default java.util.concurrent.CompletableFuture<java.lang.Void> pause​(PauseArguments args)
        The request suspends the debuggee.

        The debug adapter first sends the response and then a 'stopped' event (with reason 'pause') after the thread has been paused successfully.

      • stackTrace

        default java.util.concurrent.CompletableFuture<StackTraceResponse> stackTrace​(StackTraceArguments args)
        The request returns a stacktrace from the current execution state of a given thread.

        A client can request all stack frames by omitting the startFrame and levels arguments. For performance-conscious clients and if the corresponding capability Capabilities.getSupportsDelayedStackTraceLoading() is true, stack frames can be retrieved in a piecemeal way with the startFrame and levels arguments. The response of the stackTrace request may contain a totalFrames property that hints at the total number of frames in the stack. If a client needs this total number upfront, it can issue a request for a single (first) frame and depending on the value of totalFrames decide how to proceed. In any case a client should be prepared to receive fewer frames than requested, which is an indication that the end of the stack has been reached.

      • scopes

        default java.util.concurrent.CompletableFuture<ScopesResponse> scopes​(ScopesArguments args)
        The request returns the variable scopes for a given stack frame ID.

      • variables

        default java.util.concurrent.CompletableFuture<VariablesResponse> variables​(VariablesArguments args)
        Retrieves all child variables for the given variable reference.

        A filter can be used to limit the fetched children to either named or indexed children.

      • setVariable

        default java.util.concurrent.CompletableFuture<SetVariableResponse> setVariable​(SetVariableArguments args)
        Set the variable with the given name in the variable container to a new value. Clients should only call this request if the corresponding capability Capabilities.getSupportsSetVariable() is true.

        If a debug adapter implements both setVariable and setExpression, a client only uses setExpression if the variable has an evaluateName property.

      • source

        default java.util.concurrent.CompletableFuture<SourceResponse> source​(SourceArguments args)
        The request retrieves the source code for a given source reference.

      • threads

        default java.util.concurrent.CompletableFuture<ThreadsResponse> threads()
        The request retrieves a list of all threads.

      • modules

        default java.util.concurrent.CompletableFuture<ModulesResponse> modules​(ModulesArguments args)
        Modules can be retrieved from the debug adapter with this request which can either return all modules or a range of modules to support paging.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsModulesRequest() is true.

      • evaluate

        default java.util.concurrent.CompletableFuture<EvaluateResponse> evaluate​(EvaluateArguments args)
        Evaluates the given expression in the context of the topmost stack frame.

        The expression has access to any variables and arguments that are in scope.

      • setExpression

        default java.util.concurrent.CompletableFuture<SetExpressionResponse> setExpression​(SetExpressionArguments args)
        Evaluates the given 'value' expression and assigns it to the 'expression' which must be a modifiable l-value.

        The expressions have access to any variables and arguments that are in scope of the specified frame.

        Clients should only call this request if the corresponding capability Capabilities.getSupportsSetExpression() is true.

        If a debug adapter implements both setExpression and setVariable, a client uses setExpression if the variable has an evaluateName property.