(On | No) Syntactic Support for Error Handling

https://news.ycombinator.com/rss Hits: 15
Summary

[ On | No ] syntactic support for error handling Robert Griesemer 3 June 2025 One of the oldest and most persistent complaints about Go concerns the verbosity of error handling. We are all intimately (some may say painfully) familiar with this code pattern: x, err := call() if err != nil { // handle err } The test if err != nil can be so pervasive that it drowns out the rest of the code. This typically happens in programs that do a lot of API calls, and where handling errors is rudimentary and they are simply returned. Some programs end up with code that looks like this: func printSum(a, b string) error { x, err := strconv.Atoi(a) if err != nil { return err } y, err := strconv.Atoi(b) if err != nil { return err } fmt.Println("result:", x + y) return nil } Of the ten lines of code in this function body, only four (the calls and the last two lines) appear to do real work. The remaining six lines come across as noise. The verbosity is real, and so it’s no wonder that complaints about error handling have topped our annual user surveys for years. (For a while, the lack of generics surpassed complaints about error handling, but now that Go supports generics, error handling is back on top.) The Go team takes community feedback seriously, and so for many years now we have tried to come up with a solution for this problem, together with input from the Go community. The first explicit attempt by the Go team dates back to 2018, when Russ Cox formally described the problem as part of what we called the Go 2 effort at that time. He outlined a possible solution based on a draft design by Marcel van Lohuizen. The design was based on a check and handle mechanism and was fairly comprehensive. The draft includes a detailed analysis of alternative solutions, including comparisons with approaches taken by other languages. If you’re wondering if your particular error handling idea was previously considered, read this document! // printSum implementation using the proposed check/handle m...

First seen: 2025-06-03 16:41

Last seen: 2025-06-04 06:44