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

Tidy up error API for parser.Parse #147

Open
bufdev opened this issue May 26, 2023 · 0 comments
Open

Tidy up error API for parser.Parse #147

bufdev opened this issue May 26, 2023 · 0 comments

Comments

@bufdev
Copy link
Member

bufdev commented May 26, 2023

The Godoc says:

// If the error returned is due to a syntax error in the source, then a non-nil
// AST is also returned. If the handler chooses to not abort the parse (e.g. the
// underlying error reporter returns nil instead of an error), the parser will
// attempt to recover and keep going. This allows multiple syntax errors to be
// reported in a single pass. And it also means that more of the AST can be
// populated (erroneous productions around the syntax error will of course be
// absent).

It would be nice if we could say something more concrete, such as If the error is due to a syntax error, errors.Is(err, something) will be true. For any other error, this is an error that will result in a nil AST. Right now, to handle errors from Parse, you're determining whether or not an error is a syntax error by using the nilness of the AST, whereas in my experience most Golang APIs use the error value to determine control flow here.

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

1 participant