Author: Pretzel

When you first start programming in any language, you’re often taught to print() to the console in order to see the values of variables or just to help you debug.

As a beginner, this is an acceptable technique. As you advance in your programming career, you find out sooner or later, that print()-ing to the console to debug is easy, but comes with a lot of drawbacks. But what else should you do?

Use the debugger and use the Logging module instead.

Python created “PEP-282 — A Logging System” back in February 2002! https://www.python.org/dev/peps/pep-0282/

It was inspired by other logging packages of other languages. Logging is a little bit more complex than print(), but it is much better suited to debugging your program than print().

In our last chapter, we talked about properly catching exceptions and re-raising with a custom exception in our _do method:

def _do(self, http_method: str, endpoint: str, ep_params: Dict = None, data: Dict = None):
    full_url = self.url + endpoint
    headers = {'x-api-key': self._api_key}
    try:
        response = requests.request(method=http_method, url=full_url, verify=self._ssl_verify, 
                                    headers=headers, params=ep_params, json=data)
    except requests.exceptions.RequestException as e:
        raise TheCatApiException("Request failed") from e
    data_out = response.json()
    if response.status_code >= 200 and response.status_code <= 299:     # 200 to 299 is OK
        return data_out
    raise Exception(data_out["message"])

In this chapter, we’re going to refactor our code again to make what _do returns more generic and more useful to any code that consumes it.

In our last chapter on “WET code, DRY code, and Refactoring the low-level REST Adapter”, we refactored our code into a basic, yet reasonable low-level REST API adapter.

In this chapter, we’re going to cover proper Exception handling as well as creating our own custom Exceptions. Let’s start by looking back at our code, specifically our _do method.

This chapter is a bit of a side-bar conversation, but it’s an important one. If you’re still fairly new to programming, it’s time we introduce the concept of WET and DRY code as well as knowing when to take the time to refactor (clean-up) your code.

In the previous chapter, we wrote a simple low-level REST API Adapter. We hadn’t even passed 30 lines of code when it started to become apparent that our code was getting sloppy.

REST APIs. They’re all over the web. You could directly code against them in Python, but after a while, you start repeating yourself and your code becomes crufty and difficult to maintain. Your “high-level” business logic becomes intertwined with the “low-level” nitty-gritty logic of parsing I/O. And that’s bad news.

The smart solution is to abstract away the REST API with a “wrapper” library module more commonly known as a Software Developer Kit (SDK). Take all that nitty-gritty detail and push it down to where you don’t need to worry about it anymore and then just import your Python module and code directly against it.

If you’re using an intelligent IDE like PyCharm or VS Code, then you can leverage Type Hinting for auto-code completion. Keep your business logic separate from the boring details and your code is faster to develop and easier to maintain. Here’s how to do it: