Error handling

1. Error handling

When integrating with a web API, it's important to consider what might go wrong. After all, we're communicating with a web API over the internet, so things can go wrong. This video will explore how to gracefully handle errors and prevent common issues. Let's dive in!

2. Error status codes

To determine if an error occurred or if the request was successful, REST APIs utilize the `status_code` in the response. A status code in the 4XX or 5XX range indicates an issue. Errors in the 400 range are client errors, indicating the request from the client could not be handled properly. These are usually caused by sending a wrong header or failing to authenticate. Typically, clients can handle or manage these errors easily by fixing the request. Errors in the 500 range indicate server problems. These errors are beyond the client's control, as the server acknowledged the request but faced difficulties handling it due to server-side issues. These are typically caused by server overload, or configuration errors. Clients cannot resolve these errors but should address them in the code to prevent unexpected behavior or bugs.

3. Error status codes: examples

Some common error codes in the 400 range are 401, which means we're trying to access a protected resource and need to add authentication to our request. 404 means the resource we are trying to access does not exist on the server so we are doing something wrong. 429 will be returned when we are sending more requests to the server than it's able to handle, in this case we need to implement a rate limiter to spread out our requests over a larger period of time. Common 500 error codes are 500 Internal Server Error, which is a common catch-all error code that indicates something on the server went wrong. 502 and 504 are also errors we might encounter and are related to the server infrastructure.

4. Handling errors

The simplest way to handle API errors is by checking the response status code for any codes in the 400 and 500 ranges, which indicate an error has occurred. We can then use this status code to decide how to handle the error. However, this approach is overly simplified. An error might occur even before the request reaches the server, in which case we would not receive a response containing an error code. Fortunately, the requests library raises a ConnectionError in this case, which we can check for using a try/except block. To properly check for any errors with the API request, we should combine both approaches. The requests library makes this process straightforward.

5. raise_for_status()

The requests library has a convenient feature that automatically raises errors for any responses containing an error status code. By enabling this mode using the `raise_for_status()` function immediately after sending the request, any error code returned from the API will raise an `HTTPError`. This way, after checking for Connection errors, we can easily also check for any HTTPErrors that might have occurred.

6. Let's practice!

Now, let's put what we learned into practice!

Create Your Free Account

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