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

path: documentation of path.Match should describe error handling more precisely #32861

Closed
rillig opened this issue Jun 30, 2019 · 1 comment
Closed

Comments

@rillig
Copy link
Contributor

rillig commented Jun 30, 2019

What version of Go are you using (go version)?

go version go1.12.1 windows/amd64

Does this issue reproduce with the latest release?

yes.

What did you do?

read https://godoc.org/path#Match

https://play.golang.org/p/pdUEQ9VZniG

What did you expect to see?

Calling path.Match("malformed[", "file.txt") returns a syntax error in pattern since the bracket is not balanced.

What did you see instead?

In the call path.Match("malformed[", "file.txt"), only the first rune of the pattern needs to be inspected to see that the pattern does not match the given file name.
Therefore no error is reported in this case.
The error would be reported for path.Match("malformed[", "malformed_") though.

Because of this implementation, it is not possible to check a pattern for syntax errors by just calling path.Match(pattern, ""), which I had expected, given the wording of the documentation, which says:

The only possible returned error is ErrBadPattern, when pattern is malformed.

I had thought that when pattern is malformed would mean iff pattern is malformed.

It would be helpful if the documentation mentioned the exact error conditions, since they were surprising, at least to me. Maybe like this:

The only possible returned error is ErrBadPattern, when pattern is malformed and the malformed part of the pattern is actually necessary to determine the match.

This is still imprecise since it doesn't mention that pattern matching starts from the beginning of the string, but at least it provides a hint. If the implementation were to first check the first and the last character of the pattern and the subject, it would still be possible that path.Match("mal[formed", "m.x") skipped the error handling.

@robpike
Copy link
Contributor

robpike commented Jun 30, 2019

Duplicate of #28614

@robpike robpike marked this as a duplicate of #28614 Jun 30, 2019
@robpike robpike closed this as completed Jun 30, 2019
@golang golang locked and limited conversation to collaborators Jun 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants