golang/go

x/website/_content/blog: defer statements execute before/after the caller returns

Open

#45,889 opened on Apr 30, 2021

View on GitHub
 (6 comments) (1 reaction) (0 assignees)Go (19,008 forks)batch import
DocumentationNeedsFixhelp wantedwebsite

Repository metrics

Stars
 (133,883 stars)
PR merge metrics
 (No merged PRs in 30d)

Description

What version of Go are you using (go version)?

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

What did you do?

In this example the defer function doesn't change the returned value whereas using the named return values would do the trick in this example.

If the defer function is executed after the caller returns as this blog post suggests, that would explain it. However, the doc says defer functions are executed before the caller returns.

What did you expect to see?

The blog post and the Golang doc being consistent.

What did you see instead?

The blog post says the list of saved calls is executed after the surrounding function returns whereas the Golang doc says the list of saved calls is executed before the surrounding function returns

Contributor guide

Research direction
Review the Go specification section on defer statements and the blog post 'Defer, Panic, and Recover'. Identify the inconsistency in wording regarding when deferred functions execute. Determine which is correct based on the actual behavior, and propose a correction to either the blog post or the spec. Focus on clarifying that deferred functions execute before the surrounding function returns, but after the return values are evaluated (if any).
Tech stack
go
Domain
documentation
Issue type
Documentation
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
1
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
Under 1 hour
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
None
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
90