Re:Gopher Wrangling. Effective error handling in Go
by philosopher1234 on Wednesday June 21, 2023 @01:11PM
(#36421368)
You are wrong: https://go.dev/play/p/6PTQk0xWAAl
Re:Gopher Wrangling. Effective error handling in Go
by simiones on Thursday June 22, 2023 @05:17AM
(#36429708)
That's not how people commonly use errors, with global variables.
The way code usually looks like is this:
func foo(arg int) error {
if arg < 0 {
return fmt.Errorf("expected >0, got %d", arg)
}
if arg > 8 {
return fmt.Errorf("expected >8, got %d", arg)
}
//do stuff
}
func foo(arg int) error {
if arg < 0 {
return errors.New(fmt.Sprintf("expected >0, got %d", arg))
}
if arg > 8 {
return errors.New(fmt.Sprintf("expected >8, got %d", arg))
}
//do stuff
}
Re:Gopher Wrangling. Effective error handling in Go
by Ajnasz on Thursday June 22, 2023 @08:47AM
(#36431312)
I guess it's the same in most of languages.
If you raise a general exception with a custom message you'll have to check the message not it's type.
Re:Gopher Wrangling. Effective error handling in Go
by throwaway894345 on Thursday June 22, 2023 @09:54PM
(#36441877)
That’s not the fault of fmt.Errorf(); if you aren’t giving people a type or a value to compare against there’s nothing the standard library can do to help you. You need to try string matching or maybe reflection. The standard library can’t fix bad code. Thankfully I don’t share your experience with people commonly returning those kinds of errors (at least not where one needs to match against an error).
This is equivalent to the problem of throwing new Exception("some message") or new RuntimeException("some message") in Java, to be fair. But this is more rarely done there in my experience, especially because people are more used to defining new exception types since the stdlib has many examples of that, unlike Go (which all returns `error` for all error types).