Now that we've added in the ability to handle multiple files, the next thing we should consider is how to handle multiple errors. If I go ahead and run the word counter, passing in a file name that doesn't exist, such as noexist, when I execute this code, you can see we get the following error, letting us know that there's no such file or directory called noexist.txt. Additionally, the command also exits with the status code of 1, which we can confirm by running the following echo $? command, which will print the exit status code of the last command that we ran. In this case, it's printing out the exit status of 1. So far, this is working as expected.

However, as I mentioned, we now have the ability to handle multiple files. So what will happen if we pass in a file that does exist, for example, our words.txt, and a file that doesn't, for example, null.txt?

When I go ahead and run this command, you can see that the words.txt count is printed to the console, followed by the error message letting us know that no such file or directory exists called null.txt. If you'll remember, this line itself is printed to the standard out stream, and this line is going to be printed to standard error, which we can confirm by piping the output of standard out into /dev/null, which should only leave the standard error stream printed to the console, which you can see is the case.

This behaviour seems pretty good. However, we do unfortunately have a bit of an issue. For example, what happens if I go ahead and use the go run command again, however this time passing in the null.txt followed by the words.txt? When I run this code, you'll see we no longer get the count of words.txt being printed to the console. Instead, we just get the error caused by the fact that the null.txt file doesn't exist, as well as getting our exit status code. This behaviour really only feels partially correct. Exiting with a non-zero status code and logging to the standard error stream is certainly what we want to do when we pass in a file that doesn't exist. But ideally, we'd still like to be able to print out the count of any files that do exist.

So what's the correct behaviour? Well, whenever I get stuck deciding what's the correct behaviour for some user experience or user interface, I like to refer to how other applications work in order to gain some inspiration from. Therefore, let's go ahead and refer to the wc command we saw in the last lesson, in order to see how it handles multiple files and deals with errors. If I go ahead and run the following command, passing in the words.txt and the null.txt as follows, and for good measure, let's go ahead and compare it to our own word counter, the first difference you'll notice is that we're printing out the line of exit status 1 at the end of our code.

The wc command is also exiting with an exit status of 1, which we can confirm using the following echo command. However, in our case, we're actually printing the exit status code of 1 because of the go run command. For example, if I go ahead and build this code using go build, which creates the counter binary, then if I go ahead and call the counter words.txt and null.txt, you'll see this time we're no longer getting the exit status code of 1 log message at the end of our execution. But, just like the wc command, we are exiting with the status code of 1. Therefore, in our case, we can go ahead and ignore this first difference.

The second difference, however, and perhaps the more interesting one, is that the wc command still prints out a total, whereas our command doesn't. This is because we're exiting early, which is also impacting our code when we switch the two file names around. In our code's case, if you remember, if we pass in the null.txt, followed by the words.txt, we no longer print out the word count of the words.txt file. If we compare this to the wc command however, you'll see that the count is still printed, even though an error is encountered.

This behaviour also happens to take place if we pass in, say, three files. With the first file existing, the second file not existing, and the third file also existing as well. In this case, you can see we still print out the words.txt and lines.txt, despite having an error in the middle. Additionally, we're also printing out the total count of the two files that do exist. If we compare this to our counter code as follows, you'll see we only print out the count of the words.txt file. In my opinion, the way the wc command works is much more preferable, as it allows us to still count the number of words in the files that do exist, whilst still communicating to both the user and operating system that one of the file names was invalid.

Therefore, let's go ahead and modify our own word counter to work the same way. In order to begin, we're first going to need to modify our CountWordsInFile function, so that it also returns an error in addition to returning an int. By doing so, it will allow us to communicate with any of the function callers that an error occurred. To do so, we can modify our function signature as follows, specifying to both return an int and an error, where the integer is the first return value and the error is the second.

With that change made, as you can see, my editor is letting me know we now have some issues. So let's go about fixing them. The first thing we need to fix is to actually return two values inside of our CountWordsInFile function, considering that's what we just changed in the function definition. Therefore, let's go ahead and return an error on line 39. However, in this case, we don't have an error that occurred, so we can represent that by returning the value of nil.

Next, we then need to capture this second return value wherever we're calling this function, which in our case is only in the func main on line 22. Therefore, let's go ahead and capture the error as follows.

With this error captured, we then need to handle it in the event that it exists, which we can do by using the following if err != nil syntax we've seen before, which is pretty much 90% of how you perform error handling when it comes to Go. As for the other 10%, we'll take a look at how those are handled later on in the course.

In any case, we now need to handle the error in the event that it exists. So how to do so? Well, if we refer back to the behaviour of the wc command, passing in the words.txt, followed by the null.txt, in this case you can see we're printing out the following message to the standard error stream. Again, we can prove that this is the case by piping the stdout stream to /dev/null, which will only leave the standard error stream printed to the console.

If we take a look at this log line, you can see it begins by printing out the command's name, in this case wc, followed by a colon, followed by the error message that we receive. If we go ahead and run our code quickly, again passing in the words.txt and null.txt, you can see ours is very similar. In our case, the open: null.txt and the no such file or directory is being returned by the actual OpenFile function on line 37, and we're adding in the failed to read file context ourselves. Therefore, in order to have some similar parity to the wc command, we can just go ahead and print out this error with the prefix of our command's name, making sure to also print this out to standard error.

Therefore, in order to do so, let's go ahead and use the fmt.Fprintln function, which we've seen before. Passing an os.Stderr, followed by the name of our command, which in this case is counter. If we wanted to, we could pull this value out of the command line arguments by referencing the first value in the os.Args slice. However, if you remember back to our last lesson, this value can sometimes be a little strange, as it refers to the exact command that you used in order to actually execute the code. For example, in this case, when used with the go run command, it actually prints out the full path to the temporary directory, which is used by the Go toolchain.

Additionally, if we go ahead and build this code, and then use it with the ./counter command, you can see again it has the prefix of ./. Therefore, in my case, I'm going to go ahead and hard code this to the counter value as follows, as I think it just makes things a little tidier. Next, if I go ahead and refer back to the wc command, we then add a colon, followed by the actual error message we receive. We already have the colon added in our code, so all we need to do is just go ahead and print out the error's value.

With that, we now have our error handling code in place. However, if I go ahead and run this code, you can see that it doesn't work. This is because we're still using the log.Fatalln function of the log package whenever we encounter the error inside of our CountWordsInFile function. So instead, let's go ahead and change this code in order to return the error, so that our main function can handle it. To do so, let's go ahead and get rid of this log.Fatal line call and replace it with an early return, passing in the value of 0, which is the empty value of an integer, followed by the actual error itself.

When it comes to error handling, especially when you have two values that you want to return, the first value should typically be the empty value of the type that you're returning. This means when it comes to an integer, this is the value of 0. Or if it's a pointer, such as a pointer to an os.File, it would be the value of nil. For a string, the empty value would be an empty string. Or if you happen to have a struct, such as type Word struct, which was a struct as follows, and let's say it just had a value of string. In this case, you would just specify an empty struct as follows. In our case, we're just returning an int, so our empty value is going to be 0.

As for the actual error value, in our case, we're just going to return it as is. However, most of the time in Go, you'll want to provide additional context when you return an error inside of a function. This is done using a technique called error wrapping, which is where you wrap the error inside of a new error with your additional context. This provides a couple of benefits, such as being able to follow the chain of where an error came from, and allowing you to do some interesting things when it comes to handling the error as well. We'll take a look at that a little more later on in the course.

In order to wrap an error in Go, you can use the fmt.Errorf function of the fmt package, which accepts a format string as its first parameter, which is where you can provide your additional context. Then in order to wrap the error, you can use the %w verb inside of your format string, passing in an error operand into the variadic array. Then this function will return an error with the existing error wrapped inside. For example, let's say we wanted to wrap this error with some additional context saying that we couldn't open the file. In our case, we can do this as could not open file, and then use the %w verb as follows, passing in the error, which will then be wrapped.

Additionally, when it comes to Go, it's also enigmatic to remove any redundancy in this error string. In our case, this is the could not at the beginning of the string, as it's pretty much implied by the fact that an error occurred, that something either failed or didn't happen. Therefore, when it comes to your own error wrapping code, you can get rid of these redundant statements, such as could not or even failed to. As I mentioned before, we'll take a look at error wrapping and error handling in more detail in a later lesson. However, for the meantime, because this is the only error that we're returning inside of our code, then there's not much use in providing additional context. So let's go ahead and just remove it.

With that, we can now go ahead and test the output of our command. To do so, let's go ahead and run it with the words.txt and null.txt file that we saw before. As you can see, the behaviour of our code has now changed. We're printing out the name of our command, which in this case is counter, followed by printing out the error string, similar to what we were seeing with the wc command. However, there is one thing that's slightly different. As we're printing out the word count of the null.txt, setting it to zero. This is obviously wrong, as we don't have a null.txt file, and in the case of the wc command, this isn't happening.

In our case, the reason this is happening is because, even though we're handling the error, the loop is still continuing, and so we're still calling the fmt.Println function on line 29. Therefore, in order to prevent this from happening, we need to add some additional code into our error handling block, in order to tell the loop to continue onto the next iteration. In Go, this is done using the continue keyword, as follows. Now, if I go ahead and run the application again with the words.txt and null.txt, this time you can see we're no longer printing out the zero count for the null.txt as we were before, and it's looking pretty similar to our wc command.

However, there's currently one last thing we need to fix. Again, if I go ahead and run our current counter code and print out the exit value of the last command, you can see this time it's now being set to zero, regardless of whether or not there was an error. However, just like the wc command, we actually want this to be set to one if an error occurs, as this allows the operating system and any other processes to know that something went wrong.

However, we can't just use the os.Exit command as we were before inside of our error handling code, as this will then cause the problem where we're not printing out the total, or in the case that the files are inversed, no longer printing out any further counts once the error is encountered. Instead, we're going to need to call the os.Exit function at the end of our code if an error existed. In order to achieve this, we have a few different options. However, in this case, I'm going to go ahead and make use of a boolean in order to track whether or not an error occurred. Therefore, in order to do so, let's go ahead and create a new variable called didError, which we'll initially set to be false.

Then inside of our error handling code, let's go ahead and set the didError value to be true. Now all that remains is to go ahead and call the os.Exit function if our didError value is true, which we can do using the following if statement of if didError, calling the exit function of the os package, passing in the value of 1. Now if I go ahead and run my code as I did before, this time you can see we're getting the error message which should be printed to os.Stderr, which I can go ahead and confirm, and is also exiting with a status code of 1.

Additionally, you can also see that the count of the words.txt file is also being printed, and if we go ahead and run this with three files that we saw before, the two files that do exist are having their words counted, and the one that doesn't is being printed to standard error, and we're also getting the correct exit status code. With that, we've managed to add in support for working with multiple files, whilst at the same time, being able to handle errors in case one doesn't exist. All keeping parity with the wc command we've looked at in this and last lesson.

Not only that, but we also got to look at a new keyword, the continue keyword, which allows us to continue on to the next iteration inside of a for loop. In the next lesson, we're going to take a look at a new keyword called defer, and how we can use it to tidy up resources inside of our code.

Before moving on, make sure to go ahead and commit the changes from your main.go function, and I'll see you in the next lesson.