Introduction to errors

In this video we'll explore how Go handles errors, focusing on the basics of the error type and how to handle them effectively. So in Go, errors are values and the handling is explicit. Unlike many other languages, Go doesn't use exceptions for error handling, instead it returns them from functions and allows us to directly handle them. So let's start by understanding the error type in Go.

So the error type is just a regular interface inside the built-in package in the standard library. It has a single method called error which returns a string and this interface can be implemented on any struct that you create to define custom errors. In Go the most common way to handle errors is by returning an error as the last return value from each function and then adding an if error doesn't equal nil check right after it's called.

So let's look at an example for this. So first let's create a function let's call it might fail and this will return an error and for now we'll just return nil and then in our main.go file we can call this function and check the error explicitly so we’ll call `mightFail()`, assign its return value to `err`, and then we check if the error doesn't equal nil and then in this case we would want to do something like log for example and terminate the application. Otherwise we know our function ran successfully.

Now any time an error value is returned which is not nil, we can assume that something went wrong and we need to handle it, so in this case we're just logging the error and exiting so the simplest way to create an error is by using the errors.new function from the standard library and we can do that like so so we just call errors.new and pass in an error message so we'll just say some error occurred so that's the simplest form of error handling and go and now if we run this we should see an error and we should see it get logs and as you can see we got our log message here so we have some error occurred which is log message from here and confusingly i've used the same string in our error message so if i just change this to an error and run this it might be easier to visualize and now you can see some error occurred an error.

So far we've seen how to return and check for errors but what if we want to add more context to an error for example what if we have a number of function calls and we want to know where the error originated from go doesn't have built-in support for stack traces so that's where the fmt.errorf function can be very useful and we can use this to wrap our error with any additional context that we might have and we can use that to make it easier when debugging to see exactly where the error occurred and what the scenario was which caused the error.

So to do this let's expand our function a little bit and add multiple function calls which means makes it harder to know exactly where the error from so one way we can do this just for visualization is we can create a flaky function that will return error only sometimes and then we can make multiple calls to that in our might fail function and then we can use our fmt.errorf function to log exactly where this error happened so let's start by creating a flaky function and we'll do this to return an error maybe one out of three times or roughly one out of three times so we'll use the rand package for this so this should generate a random number and whenever it's zero it should return error because we're passing three in here it should fail roughly one in three times.

So now in our might fail function we can call this a number of times and then we'll use the fmt.errorf to make it the error returned in each instance slightly different so it's easier to debug so we'll start out with the first error function call and we'll do fmt.errorf first function failed, and we'll wrap it with the error by using the W placeholder and then we'll do second function, third and finally fourth. So if it's called four times hopefully we will see the error occur.

Otherwise we'll just return nil if we don't get any errors so now when this function is called and one of these fails we will see the different error messages based on which one failed so it should be easy to see exactly where the error originated from so now if we run our application aga