5 ms·

> Go very very much does not want application code to be type-asserting the values they receive. `switch x.(type)` is an escape hatch, not a normal pattern! And

• Yoric 1y ago
  > If you define errors with Errors.New you use string comparison. 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.
  • packetlost 1y ago
    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).
    • kiitos 1y ago
      errors.Is definitely doesn't use string comparison internally: https://cs.opensource.google/go/go/+/refs/tags/go1.24.3:src/errors/wrap.go;l=27-78 https://cs.opensource.google/go/go/+/refs/tags/go1.24.3:src/...
      • masklinn 1y ago
        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.
        • kiitos 1y ago
          See for yourself: https://go.dev/play/p/Q7IPuPS5CwQ https://go.dev/play/p/Q7IPuPS5CwQ
          • masklinn 1y ago
            Oh hell, I always forget equality doesn't go through pointers in go, you're right. And as you demonstrate I could have tested it easily enough to confirm I was reading the code correctly...
    • Yoric 1y ago
      My bad, I misunderstood your previous comment.
• kiitos 1y ago
  > A type assert/switch is exactly how you implement Error.Is [^0] errors.Is is already implemented in the stdlib, why are you implementing it again? I know that you can implement it on your custom error type, like your link shows, to customize the behavior of errors.Is. But this is rarely necessary and generally uncommon.. > If you define errors with Errors.New you use string comparison, which is only convenient if you export a top level var of the error instead of using Errors.New directly. What? If you want your callers to be able to identify ErrFoo then you're always going to define it as a package-level variable, and when you have a function that needs to return ErrFoo then it will `return ErrFoo` or `return fmt.Errorf("annotation: %w", ErrFoo)` -- and in neither case will callers use string comparison to detect ErrFoo, they'll use errors.Is, if they need to do so in the first place, which is rarely the case. This is bog-standard conventional and idiomatic stuff, the responsibility of you as the author of a package/module to support, if your consumers are expected to behave differently based on specific errors that your package/module may return. > Complex interfaces like HTTP and filesystems will want to retry on certain conditions such as timeouts, for example. Sure most error checks by volume might be satisfied with a simple nil check, it's not fair to say branching on specific errors is not common. Sure, sometimes, rarely, callers need to make decisions based on something more granular than just err != nil. In those minority of cases, they usually just need to call errors.Is to check for error identity, and in the minority of those minority of cases that they need to get even more specific details out of the error to determine what they need to do next, then they use errors.As. And, for that super-minority of situations, then sure, you'd need to define a FooError type, with whatever properties callers would need to get at, and it's likely that type would need to implement an Unwrap() method to yield some underlying wrapped error. But at no point are you, or your callers, doing type-switching on errors, or manual unwrapping, or anything like that. errors.As works with any type that implements `Error() string`, and optionally `Unwrap() error` if it wants to get freaky.