This is going to be a short post inspired by Sean Kelly’s tweet in November.
I found a reason to use named returns in #golang and now I feel pic.twitter.com/6EN3vapuHB
— Sean Kelly (@StabbyCutyou) November 15, 2017
The goal is to just document and illustrate a situation where named return variables are necessary, so with that said let’s just jump right in.
Imagine you are writing some code that uses a function that can panic, and for whatever reason (3rd party lib, backwards compatibility, etc) you can’t change that function.
func pressButton() {
fmt.Println("I'm Mr. Meeseeks, look at me!!")
// other stuff then happens, but if Jerry asks to
// remove 2 strokes from his golf game...
panic("It's gettin' weird!")
}
You still need to use that function, but if it panics you want to capture the panic and return it as an error so you write some code like this:
func doStuff() error {
var err error
// If there is a panic we need to recover in a deferred func
defer func() {
if r := recover(); r != nil {
err = errors.New("the meeseeks went crazy!")
}
}()
pressButton()
return err
}
Then you go run your code and… what’s this? Your error is nil
even when the code panics? That’s not what we wanted!
While at first it looks like our code is returning the var err error
that we create at the start of our function, the truth is our program never gets to that line of code. This means it never actually returns that specific err
variable, and altering it inside of our deferred function ends up being pointless.
Adding a Println
after the call to pressButton
but before the return really helps illustrate this:
pressButton()
// Nothing below here gets executed!
fmt.Println("we got here!")
return err
To fix this issue, we can simply use a named return variable.
func doStuff() (err error) {
// If there is a panic we need to recover in a deferred func
defer func() {
if r := recover(); r != nil {
err = errors.New("the meeseeks went crazy!")
}
}()
pressButton()
return err
}
The resulting code looks very similar, but by naming our return variable when we declare the function our program will now return the err
variable even if we never hit the return statement at the end of our doStuff
function. Because of this minor difference, we can now alter the err
variable inside of our deferred function and successfully capture the panic.
Sign up for my mailing list and I'll send you a FREE sample from my course - Web Development with Go. The sample includes 19 screencasts and the first few chapters from the book.
You will also receive emails from me about Go coding techniques, upcoming courses (including FREE ones), and course discounts.
Jon Calhoun is a full stack web developer who teaches about Go, web development, algorithms, and anything programming. If you haven't already, you should totally check out his Go courses.
Previously, Jon worked at several statups including co-founding EasyPost, a shipping API used by several fortune 500 companies. Prior to that Jon worked at Google, competed at world finals in programming competitions, and has been programming since he was a child.
Related articles
Spread the word
Did you find this page helpful? Let others know about it!
Sharing helps me continue to create both free and premium Go resources.
Want to discuss the article?
See something that is wrong, think this article could be improved, or just want to say thanks? I'd love to hear what you have to say!
You can reach me via email or via twitter.
©2024 Jonathan Calhoun. All rights reserved.