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

Add a mechanism to report syntax errors without exceptions #246

Open
Code-Grump opened this issue Apr 13, 2024 · 3 comments
Open

Add a mechanism to report syntax errors without exceptions #246

Code-Grump opened this issue Apr 13, 2024 · 3 comments

Comments

@Code-Grump
Copy link

🤔 What's the problem you're trying to solve?

In the Reqnroll project https://github.com/reqnroll, I am implementing a Roslyn-based source generator. As this runs as part of the IDE as the user is typing, it's important to keep performance in mind. As such, we'd like to avoid exception-throwing as a mechanism for reporting problems in user syntax, as these will occur frequently as the user authors their feature files.

✨ What's your proposed solution?

I would like a method added to Parser<T> which can return either a successful parse result or a failure.

A "try" method would be adequate:

public bool TryParse(ITokenScanner tokenScanner, out T result, out List<ParserException> errors)
{
    ...
}

Alternatively, some kind of "result" type could be used to represent success or failure.

⛏ Have you considered any alternatives or workarounds?

I could not see any other operations exposed by the parser that would support this exception-free model.

📚 Any additional context?

No response

@mpkorstanje
Copy link
Contributor

mpkorstanje commented Apr 13, 2024

@gasparnagy you're more familiar with .Net and Berp, what are the possibilities here?

@gasparnagy
Copy link
Member

This would not be impossible (at least in the .NET version), because the parser anyway collects the errors in a collection and only throws an exception at the end of the parsing, or when >10 errors collected.

So we would only need to change the template so that these parts are "protected virtual" so that custom parsers can override the behavior and choose to handle the errors differently.

@Code-Grump Let's keep this improvement in mind as a perf improvement, but let's not prioritize it now (or at least I cannot promise to get this done very quickly). In Visual Studio we also parse the feature files for every keystroke and the perf hit is not that significant. We use a parser wrapper there: https://github.com/reqnroll/Reqnroll.VisualStudio/blob/main/Reqnroll.VisualStudio/Editor/Services/Parser/DeveroomGherkinParser.cs (But of course this might be still necessary for the source generator.)

@mpkorstanje
Copy link
Contributor

Okay. That would be useful to keep in mind with #153 too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants