Loading...Create an account to watch this video
Full Course
Error handling in Go is essential for developing reliable applications, particularly when building command-line interfaces (CLIs). The language employs a straightforward approach where functions, such as os.Readfile(), return a value and an error. Correctly checking this error helps prevent code execution from proceeding without handling potential problems, such as non-existent files. Go encourages local error handling by requiring developers to verify whether an error is nil and react appropriately, often by returning a non-zero exit code using the exit function from the os package. This non-zero exit informs the operating system of issues, facilitating script automation. While exit codes enhance system-level communication about errors, additional methods are necessary to effectively notify users, a topic explored in subsequent lessons.
In this lesson, we're going to take a look at how to perform error handling in Go.
Typically, there are two main approaches you can take when it comes to handling errors, each of which we'll look at in a dedicated lesson in this course, as well as how each approach can be applied when building CLI applications.
If you'll remember, back in lesson two, we implemented code to read in the contents of a file using the ReadFile function of the os package. If we take a look at this function again, you can see it returns two value types. The first is a byte slice []byte, which is what we've been using in our countWords algorithm. The second value it returns is an error, which is used to represent when something goes wrong. This error can occur for a number of different reasons, such as if the file that we've named doesn't exist, or if the permissions on that file don't allow us to read it. If an error does occur inside of this ReadFile function, then the error value that's returned as the second return parameter will be set to a non-nil value. However, our code currently doesn't actually check to see if the error is not nil. Instead, if an error does occur, the code will continue as if it didn't.
To show what this looks like, if I go ahead and set the ReadFile function to load in it from a file that doesn't exist, then run the following go run command, you can see we get the result of zero, as the function operates as if it was an empty file. Whilst in some cases this may be desirable, in our case it actually isn't. Instead, we should be informing the user and the operating system that something went wrong.
Instead, let's go ahead and capture this error return value in a variable named err, which is the idiomatic name for the error variable when it comes to Go. Then, in order to check if an error occurred, we can use the following if statement of if err != nil. This is how error handling is typically performed in Go. This may feel rather simplistic compared to other languages such as Rust, Haskell or even Java. However, this simplicity is actually a bit of a strength. And it's a rather elegant way of handling errors in my opinion. This is because it forces you to handle the error whenever it occurs, and allows you to implement locality of behaviour, which is where the actual behaviour that's associated with the error is kept just underneath where the error might occur. This contrasts to using something such as a try-catch in other languages, which can sometimes make it difficult to understand where the error is actually handled.
As for actually handling the error in Go, as I mentioned at the start of this lesson, there are two common approaches. The first is to populate the error back up the call chain. This works pretty well when you have a function, such as func doSomething(), which returns an actual error, or returns an error as well as another value. In this case, if something breaks, you can then return an empty value, such as the empty string, as well as an error that you initialise using either the errors.New function, telling the caller something went wrong.
However, in our case, we're inside of the main function, which means we don't actually have an error return value that we can pass up to our caller. However, the main function does actually have something that calls it. It's not another function inside of our code, but instead it's the operating system itself. And we can communicate to the operating system that something went wrong. In languages such as C, this is achieved by returning an integer value at the end of the main function. Typically, this is a 0 if something was successful, or a non-zero value when something went wrong.
However, when it comes to Go, we don't actually have a return value we can send in the main function. If we did, then we could just use it with the actual error value itself. Therefore, in order for us to tell the process return a non-zero exit code, we achieve this by using the Exit function of the os package, which causes the current program to exit with the given status code. As you can see in the documentation, it says conventionally code 0 indicates success, whereas non-zero indicates an error. Therefore, if we go ahead and call this function with the exit code of, say, 1, we'll be informing the operating system that something went wrong.
os.Exit(1)
Now, if I open up another terminal window and run this code using the go run command, you can see this time we receive the text of an exit status one, which is the operating system telling us that something went wrong. This is pretty useful when it comes to, say, bash scripts or working with automation, as it allows you to have conditional behaviour based on whether or not your actual command was successful.
For example, here I have a simple bash script that calls the counter binary, which I can go and build using the go build command. If the execution of the counter code was successful, then the script will print out the word success, otherwise it will print out failure. Now, if I go ahead and run this script as follows, you can see that we're printing out the word failure, showing us that the exit code is working correctly. If I go ahead and then change this to be a file that does exist, which is our words.txt, then go ahead and build and run the code again, this time you can see we get a success, as well as the actual number of words being printed out.
Therefore, by returning the correct exit code in the event of an error, we're enabling our CLI application to easily be automated when it comes to working with scripts or other programs in themselves. We'll actually take a look at how we can call other programs in Go later on, and we'll be making use of the exit codes in order to know if something was successful.
Whilst using exit codes is great when it comes to informing the operating system that something went wrong, it's not actually that useful when it comes to informing users. Therefore, in the next lesson we'll take a look at how we can actually inform our users that something went wrong, and some of the nuances of doing so in a command line application.