3 ms·

You are wrong: https://go.dev/play/p/6PTQk0xWAAl https://go.dev/play/p/6PTQk0xWAAl

• simiones 3y ago
  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 } or 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 } In either of these cases, a caller of foo() can at best parse err.String() to see why foo() complained. But there is no way that errors.As or errors.Is help with the majority of errors returned by Go programs.
  • throwaway894345 3y ago
    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).
  • Ajnasz 3y ago
    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.