|
|
|
|
|
by a-poor
108 days ago
|
|
What is broken about the go error type? If anything the fact that it is a simple interface makes the `try` syntax sugar more doable – right? Let's say you have this: ```
part, err := doSomething()
if err != nil {
return nil, err
} data, err := somethingElse(part)
if err != nil {
return nil, err
} return data, nil
``` Then as long as your function followed the contract 0+ returns and then 1 `error` return, that could absolutely be turned into just the 0+ returns and auto-return error. The fact that the `Error` interface is easy to match and extend, plus the common pattern of adding an error as the last return makes this possible. What am I missing here? |
|
There's not much broken with the error type itself, but the "real" problem is that the Go team decided not to change the way errors are handled, so it becomes a question of error handling ergonomics.
The article doesn't have a clear focus unfortunately, and I think it's written by an LLM. So I think it's more useful to read the struggles on the Go team's article
https://go.dev/blog/error-syntax