5 ms·

This person just does error checking, not error handling. Every single example in this post is a bare `return err`. At least wrap the error like `return fmt.Err

This person just does error checking, not error handling. Every single example in this post is a bare `return err`. At least wrap the error like `return fmt.Errorf("could not do foo: %w", err)`.

shaan7 5y ago
Note that this can quite problematic in scenarios where the caller wants to inspect the error (example: was the error an http timeout? or a server error?). Returning the error and letting the topmost call site handle that is usually better.
- mseepgood 5y ago
  That's what `errors.Is` is for. https://pkg.go.dev/errors#Is https://pkg.go.dev/errors#Is
  - simiones 5y ago
    It would be interesting if anyone used error types in Go, but you'll be hard pressed to find libraries that do. return fmt.Errorf() all the way.
    - noisem4ker 5y ago
      In my experience, errors returned by the standard library and recent third party packages are fairly well discernible, although not in all cases. Note that you don't need custom error types, just exported Error instances. These were in use even before wrapping was introduced with Go 1.13 (2019); one had to compare or type-assert directly instead of unwrapping.
    - lox 5y ago
      You can use %w in fmt.Errorf to accomplish this.
      - simiones 5y ago
        Not really. If the original error is `fmt.Errorf("divide by 0")`, no amount of `fmt.Errorf("failed to divide: %w")` will help anyone programmatically recognize the error.
        lox 5y ago
        Yup, fair point, I thought we were talking about libraries replacing errors to obscure the original, which absolutely happens. Lots of libraries (e.g aws-sdk) do use typed errors, so wrapping them correctly for smaller libraries that compose them is important.
- lu4p 5y ago
  No you should use errors.Is(err, http.ErrHandlerTimeout) instead of simple equality.
  - shaan7 5y ago
    Thanks (and to mseepgood as well). TIL :)
jesseduffield 5y ago
wrapping the error at the source is sensible, but if you need to pass the error five levels up before reaching the function that's actually responsible for handling it (e.g. retrying after a period), I find the wrapping becomes superfluous and further obscures the intention of the function. Rust's `?` operator works well here.
- xh-dude 5y ago
  There is no categorical presumption in Go that an error invalidates what would be boxed in a Result or Option. I do think that what seems obviously true and categorical in the absence of concurrency is quite a bit more subtle when concurrent. It’s obvious when rewriting the kind of chains where ‘?’ makes perfect sense from sequential to concurrent invocation. By no means do I think Go is perfect or can’t learn from Rust but I do think it’s important to consider the tradeoffs against Go’s colorless concurrency - it’s a very compelling affordance. Like garbage collection it’s easy to show the pros and cons in a codebase the size of a demonstration but at scale it’s a decision with pros and cons.

This person just does error checking, not error handling. Every single example in this post is a bare `return err`. At least wrap the error like `return fmt.Errorf("could not do foo: %w", err)`.

shaan7 5y ago

Note that this can quite problematic in scenarios where the caller wants to inspect the error (example: was the error an http timeout? or a server error?). Returning the error and letting the topmost call site handle that is usually better.

mseepgood 5y ago
That's what `errors.Is` is for. https://pkg.go.dev/errors#Is https://pkg.go.dev/errors#Is
- simiones 5y ago
  It would be interesting if anyone used error types in Go, but you'll be hard pressed to find libraries that do. return fmt.Errorf() all the way.
  - noisem4ker 5y ago
    In my experience, errors returned by the standard library and recent third party packages are fairly well discernible, although not in all cases. Note that you don't need custom error types, just exported Error instances. These were in use even before wrapping was introduced with Go 1.13 (2019); one had to compare or type-assert directly instead of unwrapping.
  - lox 5y ago
    You can use %w in fmt.Errorf to accomplish this.
    - simiones 5y ago
      Not really. If the original error is `fmt.Errorf("divide by 0")`, no amount of `fmt.Errorf("failed to divide: %w")` will help anyone programmatically recognize the error.
      - lox 5y ago
        Yup, fair point, I thought we were talking about libraries replacing errors to obscure the original, which absolutely happens. Lots of libraries (e.g aws-sdk) do use typed errors, so wrapping them correctly for smaller libraries that compose them is important.
lu4p 5y ago
No you should use errors.Is(err, http.ErrHandlerTimeout) instead of simple equality.
- shaan7 5y ago
  Thanks (and to mseepgood as well). TIL :)

jesseduffield 5y ago

wrapping the error at the source is sensible, but if you need to pass the error five levels up before reaching the function that's actually responsible for handling it (e.g. retrying after a period), I find the wrapping becomes superfluous and further obscures the intention of the function. Rust's `?` operator works well here.

xh-dude 5y ago
There is no categorical presumption in Go that an error invalidates what would be boxed in a Result or Option. I do think that what seems obviously true and categorical in the absence of concurrency is quite a bit more subtle when concurrent. It’s obvious when rewriting the kind of chains where ‘?’ makes perfect sense from sequential to concurrent invocation. By no means do I think Go is perfect or can’t learn from Rust but I do think it’s important to consider the tradeoffs against Go’s colorless concurrency - it’s a very compelling affordance. Like garbage collection it’s easy to show the pros and cons in a codebase the size of a demonstration but at scale it’s a decision with pros and cons.