4 ms·

For me, the issue with error handling is that while errors are explicitly stated, they are often poorly handled. Rarely have I seen the handling of multiple rea

• cnity 2y ago
  As a regular Go user, I agree with this take. Though the tools exist, error wrapping and checking (with errors.Is and so on) is actually pretty rare in my experience. Positive example of good and appropriate usage here: https://github.com/coder/websocket/blob/master/internal/examples/chat/chat.go#L74 https://github.com/coder/websocket/blob/master/internal/exam...
• Cthulhu_ 2y ago
  This is down to developer style and agreements though; Go has typed errors and a set of utilities to match them [0]. Not using those is a choice, just like how in Java you can just `catch (Exception e)` after calling a dozen methods that might each throw a different exception. [0] https://pkg.go.dev/errors https://pkg.go.dev/errors
  • Yoric 2y ago
    Interestingly, every time (and I mean _every_ time) that I've tried to use `errors.As` on errors raised by lib code, I found out that the lib just went with "nah, I'm just going to use `errors.New` or `fmt.Errorf`", which makes the error impossible to match. So... I'd say that this is a fumble in the design of Go.
    • wbl 2y ago
      %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.
      • 2y ago