Re:(On | No) Syntactic Support for Error Handling
by packetlost on Wednesday June 04, 2025 @10:34AM
(#44181135)
I was actually referring to the implementation of errors.Is, which uses string comparison internally if you use the error type returned by errors.New and a type cast or switch if you use a custom type (or the cases where the stdlib defines a custom error type).
Re:(On | No) Syntactic Support for Error Handling
by kiitos on Wednesday June 04, 2025 @04:40PM
(#44185268)
errors.Is definitely doesn't use string comparison internally:
https://cs.opensource.google/go/go/+/refs/tags/go1.24.3:src/...
Re:(On | No) Syntactic Support for Error Handling
by masklinn on Thursday June 05, 2025 @01:08AM
(#44188474)
Of course it does. What do you think an errors.New contains and how do you figure it compares by value when checking placeholder errors?
The answer is that errors.New just wraps the error message in an errorString struct, and the second line of `is` is a string comparison.
Re:(On | No) Syntactic Support for Error Handling
by kiitos on Friday June 06, 2025 @12:14PM
(#44202340)
See for yourself: https://go.dev/play/p/Q7IPuPS5CwQ
With `Errors.New`, you're expected to provide a human-readable message. By definition, this message may change. Relying on this string comparison is a recipe for later breakages. But even if it worked, this would require documenting the exact error string returned by the function. Have you _ever_ seen a function containing such information in the documentation?
As for `switch x.(type)`, it doesn't support any kind of unwrapping, which means that it's going to fail if someone in the stack just decides to add a `fmt.Errorf` along the way. So you need all the functions in the stack to promise that they're never going to add an annotation detailing what the code was doing when the error was raised. Which is a shame, because `fmt.Errorf` is often a good practice.