Handling errors

1. Handling errors

Welcome back! We just learned how to handle PUT and DELETE operations with FastAPI. Now we will learn about handling errors.

2. Two Main Reasons To Handle Errors

There are two main reasons for errors. First, errors caused by users of the API. This includes using an invalid or outdated URI or missing or incorrect input. For example, an API user could request to delete an object that doesn't exist. In this case we check if we have the item and respond with an error if we don't. The other main reason for errors is server errors. These happen when something unexpectedly goes wrong. For example, the app could get an exception when trying to delete an object. In this case we wrap our code in a try block and respond with an error when there is an Exception.

3. HTTP Status Codes: "Levels of Yelling"

To communicate about the status of requests, APIs use HTTP status codes. Status codes enable APIs to clearly communicate status in every response. Status codes are specifically defined in the HTTP protocol. They range from 100 to 599, and are categorized by their first numbers, 1 through 5. The categories are like the level of yelling we would use if we were trying to say something in a loud restaurant. 100-level status codes do not provide any information on success or failure, so they are like whispers. 200-level status codes indicate different kinds of success, kind of like a crisp "Aha!" 300-level status codes are for redirection as if to exclaim, "I didn't do it!" 400-level status codes are for client errors, like yelling, "You did it!" 500-level status codes are for server errors, like screaming, "He's choking!"

4. Common HTTP Status Codes

Let's learn about some of the most common status codes we will use. 200-level status codes indicate success. 200 is the most common code and simply means "OK." 201 indicates an object was created, so it is usually used for POST operations. 202 is noncommittal. It often indicates that a job has been accepted, as if to say, "We are working on it!" 204 indicates no content. It often means that an object has been deleted, or there is otherwise no useful information to send back. What about "unsuccessful" responses? 301 means the URI has been permanently changed and should provide a redirect in the response. 400 indicates a bad request, which means the client made an error. 404 means, more specifically, that the client requested a resource that was not found. That resource could be a URI or an object managed by the API. The server returns 500 in any situation it can't handle. This could due to an exception thrown by the FastAPI app but could also be caused by anything else the server is doing that interferes with the response. For example, a bad connection to a database would likely cause some 500-level errors.

5. Handling Errors With Status Codes

We can't do anything about outside server errors, but we can handle errors within our FastAPI application. We just need to import HTTPException from FastAPI, and raise it with an appropriate status code and detailed message. Here, we have a delete endpoint raise an HTTPException with status code 404 to indicate that the item to delete was not found.

6. Let's practice!

Now, let's practice handling errors in FastAPI!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.