This article discusses issues caused by reusing error variables in Go code. I will begin by illustrating the problem with a fictional company called ACME Corporation and its software engineer Wile E. Then I will present trivial examples to reveal the problem and how to avoid it.
The story of a reused Go error variable
A user opened a new issue to ACME Corporation because he noticed that users could enter any string into the phone number on the contact form. Wile E. is in charge of implementing a fix.
Wile E. examines the code:
func StoreAllContacts() {
for _, c := range contactsToStore {
err := legacy.StoreContact(&c)
if err != nil {
fmt.Printf("Error storing %v: %v\n", c, err)
} else {
fmt.Printf("Contact NAME: %s, SURNAME: %s, PHONE: %s stored successfully!\n", c.Name, c.Surname, c.PhoneNumber)
}
}
}
When he runs the code, he sees the following output:
Contact NAME: John, SURNAME: Doe, PHONE: (012) 3456789 stored successfully!
Contact NAME: Jane, SURNAME: Doe, PHONE: (089) 3456789 stored successfully!
Contact NAME: Tom, SURNAME: Doe, PHONE: (083) 1234567 stored successfully!
Wile thinks, "OK. Fixing the code should be easy. I will add the check for the phone number format just before calling the StoreContact function."
Then, Wile produces the following code:
const phoneNumberRe = `\(\d{3}\) \d{7}`
func validatePhoneNumber(phoneNumber string) (bool, error) {
re, err := regexp.Compile(phoneNumberRe)
if err != nil {
return false, err
}
return re.MatchString(phoneNumber), nil
}
func StoreAllContacts() {
for _, c := range contactsToStore {
valid, err := validatePhoneNumber(c.PhoneNumber)
if err != nil {
fmt.Printf("Invalid phone number RE ('%s'). Validation ignored.\n", phoneNumberRe)
}
if !valid {
fmt.Printf("Invalid phone number '%s' for '%s %s'", c.PhoneNumber, c.Name, c.Surname)
}
err = legacy.StoreContact(&c)
if err != nil {
fmt.Printf("Error storing %v: %v\n", c, err)
}
}
}
Wile runs the code, but the output is not what he expected:
Error storing {John Doe (012) 3456789}: <nil>
Error storing {Jane Doe (089) 3456789}: <nil>
Error storing {Tom Doe (083) 1234567}: <nil>
Wile wonders what is happening: "The program enters the if err != nil branch, but then the output of the fmt.Printf shows that err is nil..."
What makes Wile even more confused is that he didn't change anything inside StoreContact. So he wonders why the behavior changed.
After some debugging, Wile decides to look at the StoreContact method:
func StoreContact(c *Contact) *ContactError {
if err := c.validate(); err != nil {
return err
}
// ... store the contact somewhere
return nil
}
Wile: "Oh! There it is!"
Wile gets permission to fix the function as follows:
func StoreContact(c *Contact) error {
if err := c.validate(); err != nil {
return err
}
// ... store the contact somewhere
return nil
}
When he reruns the code, it finally works as expected. But how did he arrive at this fix?
The fix explained: The hidden dynamic type
To understand the issue, let's look at the following code:
package main
import "fmt"
type MyTestError struct {
}
func (MyTestError) Error() string {
return "Test Error String"
}
func main() {
var err error // (1)
fmt.Println("Is err nil?", err == nil)
var mytesterror *MyTestError // (2)
fmt.Println("Is mytesterror nil?", mytesterror == nil)
err = mytesterror // (3)
fmt.Println("Is err nil?", err == nil)
}
Here are descriptions of the commented-out numbers:
- We create a variable of type
error. We didn't assign any value to it, so it will benil. - We create a variable of type
*MyTestError. As before, we didn't give any value to it, so it will benil. - We assign
mytesterror(nil) toerr. Sincemytesterroris nil, should be nil too.
Let's try to run the code (you can run it at the Go Playground):
Is err nil? true
Is mytesterror nil? true
Is err nil? false
The reason for this unexpected behavior is that the interface type in Go is composed of a value and a dynamic type. The interface is considered nil only when the value and the type are nil.
With that in mind, let's look again at the code:
- We create a variable of type
error. We didn't assign any value to it, so it will benil. - We create a variable of type
*MyTestError. As before, we didn't give any value to it, so it will benil. - We assign
mytesterror(that is,nil) toerr. After this assignment, the value of theerrinterface isnil, but the type is*MyTestError. As explained, an interface with a non-nil type is not nil even if the value isnil.
To make the issue more evident, let's run the following code:
package main
import "fmt"
type MyTestError struct {
}
func (MyTestError) Error() string {
return "Test Error String"
}
func main() {
var err error // (1)
fmt.Println("Type of err:", reflect.TypeOf(err))
fmt.Println("Is err nil?", err == nil)
var mytesterror *MyTestError // (2)
fmt.Println("Type of mytesterror:", reflect.TypeOf(mytesterror))
fmt.Println("Is mytesterror nil?", mytesterror == nil)
err = mytesterror // (3)
fmt.Println("Type of err:", reflect.TypeOf(err))
fmt.Println("Is err nil?", err == nil)
}
The output is:
Type of err: <nil>
Is err nil? true
Type of mytesterror: *main.MyTestError
Is mytesterror nil? true
Type of err: *main.MyTestError
Is err nil? false
The assignment changed the type of err from <nil> to *main.MyTestError.
The same happens with code like this:
package main
import (
"fmt"
"reflect"
)
type MyTestError struct {
}
func (MyTestError) Error() string {
return "Test Error String"
}
func MyTestFunc() error {
var err *MyTestError
return err
}
func main() {
err := MyTestFunc()
if err != nil {
fmt.Println("An error has occurred: ", err)
fmt.Println("Type of err: ", reflect.TypeOf(err))
return
}
fmt.Println("Success!")
}
If you try to run it in Go Playground, you will get the following output:
An error has occurred: <nil>
Type of err: *main.MyTestError
The reason why this happens should now be apparent by now: to return the error, Go copied the value of err (of type *MyTestError) to a variable of type error: exactly as we did in the previous example.
We can quickly fix the code returning a naked nil:
package main
import (
"fmt"
"reflect"
)
type MyTestError struct {
}
func (MyTestError) Error() string {
return "Test Error String"
}
func MyTestFunc() error {
var err *MyTestError
err = err // let's do something with the variable to avoid compiling error
return nil
}
func main() {
err := MyTestFunc()
if err != nil {
fmt.Println("An error has occurred: ", err)
fmt.Println("Type of err: ", reflect.TypeOf(err))
return
}
fmt.Println("Success!")
}
Running the code in the Go Playground we now get the following output:
Success!
Three cases to keep in mind
Reusing error variables and returning custom error structures is a widespread practice, and there isn't anything wrong with that. However, you should keep the form of the returned error in mind when checking it for a nil value:
-
If you control the source code of the called function, ensure it returns an
errorinterface and always returns a nakednilvalue. -
If the function you call returns a concrete object, use a dedicated variable to store that function error.
-
In all the other cases, if you see weird behaviour where Go says that a
nilvariable isnot nil, you can always use thereflectpackage to check the value specifically:reflect.ValueOf(err).IsNil()
Summary
I hope this has expanded your knowledge of the Go language. Please leave a comment below if you have questions about this article. As always, we welcome your feedback.
