Go Error Handling (Part 3) — The errors Package

Photo by freestocks on Unsplash

The Go standard library's package makes it quick and easy to create error variables. Once the error variables are created, you can then use the if-statement pattern to decide what to do with it.

This article is part of the Error Handling in Go series.

The error’s package is a popular alternative to using Go’s built-in type. That’s because using this built-in (interface) type requires a bit of leg-work, in terms of defining an error (struct) data type and a corresponding method (as demoed in Part 2).

On the other hand, the errors package doesn’t require any of this extra setup; instead, you can go straight to creating error variables using the package’s function.

Line 4: We’re importing the errors package.

Lines 8–16: We created the lessThanTen function. This functions requires an integer argument and returns 2 output parameters, a string and an error value. This function completes successfully if you pass in an integer that’s less than 10, as indicated by the return value (line 11). If you pass in an invalid integer, i.e. an integer that’s 10 or greater, then the function fails and creates+returns an error value (line 14).

Tip: It’s best practice for functions to always return an error value. If your function has multiple return value’s then the convention is that the last output parameter should return the error value. This error value acts as indicator on whether the function ran successfully and it also lets you implement the follow on if-statement pattern.

Line 20: We call our function with a valid argument. This means that we get a error value so that the error-handling code block doesn’t get triggered (lines 22–23).

Line 27: We call our function again, but this time with an invalid argument. This time we do get an actual error value. This time the error-handling code block does get executed (lines 29–30).

Lines 29–30: The error-handling involves printing out the error value (line 29). However, as mentioned in Part 2 of this series, the tries to be helpful and automatically runs the method instead. It the executes (line 30). This statement normally notifies the parent function that it has ended so that the parent functions continues. However, since in this example, the return function is executed in the top-level function, it causes the program to exit.

Line 32: The program never reaches this line because it exited on line 30.

A closer look at the package

Ok, so far we’ve established that it’s easier to create error variables using the errors package, rather than using the built-in type. But the truth is, we’re still using the built-in error type behind the scenes, via the errors package. If you take a look at the package’s source code, you’ll find that it defines a struct for storing errors and an Error() method for that struct:

  // errorString is a trivial implementation of error.
type errorString struct {
s string
}

func (e *errorString) Error() string {
return e.s
}

Don’t worry too much if this code block doesn’t make sense, that’s the beauty of Go packages, you can get away with using packages without needing to know about their inner workings. All good things come in small packages ;)

Further reading

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store