4 ms·

The Day the Linter Broke My Code

• eik 1y ago
  Having looked at the problems that can arise with errors.As: https://news.ycombinator.com/item?id=44959638 https://news.ycombinator.com/item?id=44959638 Let's now look at how errors.Is can introduce subtle bugs that can affect the reliability of error checking, especially when trying to determine the root cause of an error. How one letter can make such a difference…
• ecnahc515 1y ago
  If the the OP is the author, did consider filing a bug with errcheck? It should be possible for errcheck to check if the comparison is being done within an `Is(err error) bool` method and skip the warning in that case, or even better: it could check if your using `errors.Is` within an `Is` method and warn in that case!
  • eik 1y ago
    The linter in the post is `err113`. `errortype` does already warn: https://github.com/fillmore-labs/errortype#errortype https://github.com/fillmore-labs/errortype#errortype
    • ecnahc515 1y ago
      Ah right, wrong linter. Thanks for confirming!
• cronelius 1y ago
  Isn't this what Unwrap() is for? errors.Is calls Unwrap if it's available and then compares _that_ error.
  • eik 1y ago
    Yes, but “an Is method should only shallowly compare err and the target and not call Unwrap on either”: https://pkg.go.dev/errors#Is https://pkg.go.dev/errors#Is