Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debug Protocol: Allow exception conditions to be specified by the protocol #155

Open
richardstanton opened this issue Aug 16, 2017 · 4 comments
Labels
feature-request Request for new features or functionality

Comments

@richardstanton
Copy link
Member

In Visual Studio, users can ignore first chance exceptions when they are raised in specific modules. This is useful when an external component raises a lot of exceptions that the user does not care about. This feature can be supported by the protocol by adding the concept of exception conditions. Although these conditions are currently either "Module == name" or "Module != name" this proposal lets the condition type be specified in case other condition types are added.

/** An ExceptionOptions assigns configuration options to a set of exceptions.*/
export interface ExceptionOptions {

    // ....

    /** A set of conditions used to determine whether the exception should result in a break.
        The debugger will break only if the exception matches all listed conditions.*/
    conditions?: ExceptionCondition[];
}

/** Condition to determine if the exception should be handled by the debugger.*/
export interface ExceptionCondition {
    /** Type of the condition.*/
    type: 'module';
    /** Operation to apply to the condition value.*/
    operator?: 'equals' | 'notEquals';
    /** Value of the condition.*/
    value: string;
}

/** Information about the capabilities of a debug adapter.*/
export interface Capabilities {

    // ....

    /** The debug adapter supports using exception conditions in exception options.*/
    supportsExceptionConditions?: boolean;
}

@weinand @andrewcrawley @gregg-miskelly

@weinand weinand self-assigned this Aug 16, 2017
@gregg-miskelly
Copy link
Member

LGTM

@weinand
Copy link
Contributor

weinand commented Aug 21, 2017

Since the DAP already has a notion of a breakpoint condition, I would like to align exception conditions to breakpoint conditions (and other similar constructs).

Neither for breakpoint conditions, nor for the eval request did we specify the concrete syntax of those conditions and/or expressions (since the syntax would be language specific).

Would it be possible to just use a string typed attribute condition in the ExceptionOptions?
A language agnostic debugger like VS Code would offer a text input box to specify the condition and the DA would return an error in case of a syntax error?

@andrewcrawley
Copy link

Breakpoint conditions and evaluations are language-specific, as you noted, so it makes sense to have a free-form experience. Exception conditions (at least in VS) are a bit different, though - the only exception condition VS supports is "Only break if the exception is/is not in this module", and it's exposed through a query-builder sort of UI:

image

We don't have any way to expose a free-form text field to users. We could potentially convert the conditions designed using the UI into a language-specific string, but that would require adapter authors to write a component on the VS side that would do the translation, which we've tried to avoid.

@weinand weinand transferred this issue from microsoft/vscode-debugadapter-node Nov 6, 2020
@weinand weinand added the feature-request Request for new features or functionality label Nov 9, 2020
@weinand
Copy link
Contributor

weinand commented Dec 10, 2020

@richardstanton fyi:
With #137 we have added condition support for exceptions in a way that is aligned with conditional breakpoints. VS Code already supports the new DAP feature and it would be possible to have conditions like "moduleName == foo && moduleName == bar".

@weinand weinand removed their assignment Nov 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality
Projects
None yet
Development

No branches or pull requests

4 participants