5 ms·

%W exists to solve this

• the_gipsy 2y ago
  How? Stringly matching? That's not typesafe at all.
  • wbl 2y ago
    No it wraps the underlying error
    • the_gipsy 2y ago
      But the underlying error stays unmatchable. Doesn't sound like a solution if you have to duplicate every error type, and worse, they don't even map 1:1 but now you have the same underlying error wrapped to god knows how many different errors. For example, the lib produces some an error "bad file descriptor". You'll be wrapping it when you call fileOpen, fileDelete, etc etc 20 times. So you will be wrapping it in "open error", "delete error", etc, 20 times. You cannot try to match it to "bad file descriptor", that information is lost, you now have 20 relatively useless errors. Except if you stringly match.
      • wbl 2y ago
        https://pkg.go.dev/errors#Is https://pkg.go.dev/errors#Is and https://pkg.go.dev/fmt#Errorf https://pkg.go.dev/fmt#Errorf clearly state that there is a way to match these errors if the package exposes the values, which the stdlib does.
        • the_gipsy 2y ago
          Ah okay, it seems to work because errors are pointers, and errors.Is just checks for equality.
        • Yoric 2y ago
          Which only works when the error itself doesn't contain any information. It's better than nothing, of course.
• Yoric 2y ago
  It would, if people actually defined new errors. But, as I mentioned in my message, people just use `errors.New` or `fmt.Errorf`, all the way down, so you end up with errors that cannot be matched. Which means, in turn, that if these are errors that should be handled properly (and not just propagated/logged), they cannot.