The Day the Linter Broke My Code
3 days ago
- #Linters
- #Error Handling
- #Go
- Designing custom errors in Go involves implementing the `Error`, `Is`, and `Unwrap` methods correctly.
- The `DataEOFError` type includes the filename and is considered equal to `io.ErrUnexpectedEOF` via the `Is` method.
- The `ProcessingFailedError` type contains a processing ID and wraps a `Reason` error, with instances not being equal.
- Using `errors.Is()` for error comparison is preferred, but direct comparison (`==`) is required inside an `Is` method.
- A linter (`err113`) incorrectly suggested replacing direct comparison with `errors.Is()` in the `Is` method, breaking error handling semantics.
- The `errors.Is()` function is not symmetrical and should not be used within an `Is` method to avoid incorrect error equivalence.
- A real-world example (`fluxcd Controller Runtime`) demonstrates how incorrect `Is` implementation leads to unexpected error matching.
- Key principles: implement `Is` with direct comparison, be cautious with linter suggestions, and thoroughly test error types.