4 ms·

I'm guessing you're being sarcastic. If so, it's not really a fair criticism. Go has properly-typed return values (not just parsing text from stdout) and any ty

I'm guessing you're being sarcastic. If so, it's not really a fair criticism. Go has properly-typed return values (not just parsing text from stdout) and any type can implement the error interface, allowing for error types with any custom, properly-typed attributes. You use Go's type assertion or errors.Is / errors.As to handle the latter.

coryrc 3y ago
Maybe it's my job, but I don't see a lot of Go code treating errors as anything but strings. Errors I get from Go programs are similarly vague and redundant and lacking context. ("error from RPC: failure making from call: couldn't complete operation: 7 is not a valid flag" ah thanks, so much better than stack trace) Also it's the weekend and I'm just bitching.
- benhoyt 3y ago
  I think that's a fair critique. You have to really put thought into good error messages and error handling. When you do, they're nicer and more informative than an ugly stack trace. But a poor error message chain like the one you've shown is significantly less helpful than a stack trace.
- stouset 3y ago
  Yes, but don’t you value the fact that this error message was painstakingly crafted by hand under the care of skilled golang artisans instead of being mass-produced by an automated exception handler?
- ttymck 3y ago
  Yeah because that's the error interface? It's literally a method that returns string. Unfortunately, I guess after the fact they decided pattern matching was useful, so they did it via reflection (errors.As). But they don't warn you that errors.Is might return false for a true errors.As, it is certainly a mess, but the pedagogy could be improved.
- zaphirplane 3y ago
  > Also it's the weekend and I'm just bitching You prefer and in a better mood during the working week ? Interesting
  - Brian_K_White 3y ago
    You jump to a critical interpretation instead of allowing for instance "It's the weekend when I'm off the clock and don't police myself so much"? Interrsting.
- Patrickmi 3y ago
  [dead]
- maccard 3y ago
  I'd like to join the weekend bitching. I do think go's errors are often shitty. Stacktraces are easy to get with [0] and you can always do fmt.Errorf("%s", string(debug.Stack()) to get them in an error. I've not profiled them in go, but in native code they're horribly inefficient to gather so you don't want to be using them unless you really want to I'd bet That said, other applications have exceptions and people still manage to write functions that return a Boolean to indicate success, and log an equally unhelpful message rather than returning anything I can work with. Maybe we need new programmers. [0] https://pkg.go.dev/runtime/debug#Stack https://pkg.go.dev/runtime/debug#Stack

coryrc 3y ago

Maybe it's my job, but I don't see a lot of Go code treating errors as anything but strings. Errors I get from Go programs are similarly vague and redundant and lacking context. ("error from RPC: failure making from call: couldn't complete operation: 7 is not a valid flag" ah thanks, so much better than stack trace) Also it's the weekend and I'm just bitching.

benhoyt 3y ago
I think that's a fair critique. You have to really put thought into good error messages and error handling. When you do, they're nicer and more informative than an ugly stack trace. But a poor error message chain like the one you've shown is significantly less helpful than a stack trace.
stouset 3y ago
Yes, but don’t you value the fact that this error message was painstakingly crafted by hand under the care of skilled golang artisans instead of being mass-produced by an automated exception handler?
ttymck 3y ago
Yeah because that's the error interface? It's literally a method that returns string. Unfortunately, I guess after the fact they decided pattern matching was useful, so they did it via reflection (errors.As). But they don't warn you that errors.Is might return false for a true errors.As, it is certainly a mess, but the pedagogy could be improved.
zaphirplane 3y ago
> Also it's the weekend and I'm just bitching You prefer and in a better mood during the working week ? Interesting
- Brian_K_White 3y ago
  You jump to a critical interpretation instead of allowing for instance "It's the weekend when I'm off the clock and don't police myself so much"? Interrsting.
Patrickmi 3y ago
[dead]
maccard 3y ago
I'd like to join the weekend bitching. I do think go's errors are often shitty. Stacktraces are easy to get with [0] and you can always do fmt.Errorf("%s", string(debug.Stack()) to get them in an error. I've not profiled them in go, but in native code they're horribly inefficient to gather so you don't want to be using them unless you really want to I'd bet That said, other applications have exceptions and people still manage to write functions that return a Boolean to indicate success, and log an equally unhelpful message rather than returning anything I can work with. Maybe we need new programmers. [0] https://pkg.go.dev/runtime/debug#Stack https://pkg.go.dev/runtime/debug#Stack