proposal: stdlib: reduced boilerplate for proposals to reduce error handling boilerplate

[seebs]

Proposal Details

Just as go programs tend to end up with a large amount of boilerplate code for error-handling, go issue trackers end up with a large amount of boilerplate proposals for reducing the amount of boilerplate code for error-handling. It's been estimated* that up to 10% of go developer time is spent writing about reducing the boilerplate code used for error-handling.

[*] very badly

Rather than pursuing some kind of significant redesign of the issue-tracker to accommodate this, we propose a simple mechanism in which the boilerplate is reduced using simple conventions, easily adopted by an experienced user, and allowing precise writing of proposals to eliminate error-handling boilerplate, while drastically reducing their size in the common case.

Optimizations

To begin with, we simply omit the problem statement in all future proposals. At this point, we may safely assume that everyone is aware of the problem. Thus, the entire preamble, and the example showing a section of code with several consecutive error-return blocks, may be omitted. Instead, the proposal being tagged pkg/errors is assumed to imply a boilerplate proposal. (In the unlikely event of a proposal on another topic, introduce it with a clarification that it's not a boilerplate proposal. This is unlikely to affect a real use case in the wild.)

We omit code blocks used to show a standard example; the standard if err != nil {...} block can be entirely omitted, and you can show only the new form.

In general, explanations of why we are looking at yet another error-handling proposal, justifications for writing such proposals, and so on, may be omitted. The experienced reader is likely aware.

Instead, each proposal can start with a brief summary describing the basic family of error-handling boilerplate removal contemplated (implicit test-and-return, exception-like unwinding, etcetera) and if applicable the language or environment from which its idiom derives.

Comments

We also optimize the process of commenting on error-handling boilerplate proposals.

"I don't think error handling is a big problem." You may omit this comment; we're all aware that not everyone objects to the current state of affairs.

"I think error handling is a big problem." You may also omit this comment; we're all aware that not everyone is happy with the current state of affairs.

"The HotSpot JVM's bump allocator can do an allocation in three instructions." Sir, this is a Wendy's.

Links to, and discussions of, competing error-handling proposals are likewise unnecessary; people following these proposals are generally aware of the field and will be making the comparisons already. Specific comparisons of how a competing proposal handles a specific case may be useful.

Future Directions

With these changes, I think we can all look forward to many happy years of streamlined and more expressive writing of proposals to reduce error-handling boilerplate in Go.

[deltamualpha]

This proposal does not take into account my specific requirements and peccadilloes about the proposal process, which I will nevertheless fail to provide a reasonable or coherent explication of. Rest assured, however, that I'll tell everyone that this change would represent the clearest sign yet that Google is a poor steward of the go programming language, and there should be a fork about it.

[gabyhelp]

Related Issues

• proposal: handle error in minimal way #57552 (closed)
• proposal: Go 2: Error handling that is compact and composeable #55026 (closed)
• proposal: Go 2: error handling: try statement with handler #56165 (closed)
• proposal: Go2: error handling shortening #62378 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[lalaithion]

I don’t think error handling proposals are a big problem. Writing out the reasoning for each error handling proposal leads to clearer, more readable error handling proposals. While 99% of error handling proposals have identical sections, and this would have the side effect that new proposals with interesting differences from the norm would be more immediately apparent, it also encourages laziness, and many authors will simply use the default without thinking.

[Merovius]

I believe we can optimize this even further: Any error handling proposal simply contains 1. (only if applicable) a single code block demonstrating the new sigil/keyword/predeclared identifier/order of blocks in which it differs from previous proposals. 2. (this space intentionally left blank)

That will cause @gabyhelp to helpfully link to a list of previous, materially identical proposals.

Comments can then be reduced to "Closing as duplicate of <first issue mentioned>". We might want to augment @gopherbot to automate this step.

[thediveo]

can't you simply provide an error handling proposal "template" that doesn't need any insertions or edits?

[lpar]

ChatGPT seems to be pretty good at generating Go error handling proposals based on its extensive training set.

[as]

⠀

[ldemailly]

I believe this was april fool's 2025 and thus can be closed and not actually be inside Proposals?

[seankhliao]

Overall, I think we'd want to move proposals in the opposite direction, that is to require more information up front from the proposer #70625 .

While there are many error handling proposals, it is clear that not all of them have the same goals, or understanding of the problem space and previous attempts. Omitting the information in proposals leads to more confusion.

As for comments, while duplicate comments of the same nature are just noise that clog up the discussion, silencing dissent is not the way to go. As we can see from many previous proposals, it can be preferable to take no action rather than sleepwalk into accepting a subpar proposal.

As for @Merovius 's suggestion, many proposals are closed as fill-in-the-missing-syntax-variation in a catalogue I maintain