Python Exception Class Hierarchy

Python Exception Handling – AssertionError

Making our way through our detailed Python Exception Handling series, today we’re going over the AssertionError. Like many programming languages, Python includes a built-in assert statement that allows you to create simple debug message outputs based on simple logical assertions. When such an assert statement fails (i.e. returns a False-y value), an AssertionError is raised.

In this article we’ll explore the AssertionError in more detail, starting with where it resides in the overall Python Exception Class Hierarchy. We’ll also dig into some functional Python code samples that illustrate how assert statements can be used, and how the failure of such a statement will raise an AssertionError that should be caught and handled, just like any other error. Let’s get to it!

The Technical Rundown

All Python exceptions inherit from the BaseException class, or extend from an inherited class therein. The full exception hierarchy of this error is:

Full Code Sample

Below is the full code sample we’ll be using in this article. It can be copied and pasted if you’d like to play with the code yourself and see how everything works.

This code sample also uses the Logging utility class, the source of which can be found here on GitHub.

When Should You Use It?

As discussed in the introduction, an AssertionError can only occur when an assert statement fails. Therefore, an AssertionError should never be a surprise or appear in a section of your application code that is unexpected — every time you write an assert statement, you should also provide appropriate exception handling code to deal with an inevitable assert failure.

To illustrate how assert statements work we’ll be performing some basic equivalence testing to determine if one object is equal to a second object. To make things a bit more interesting we’ve created a simple custom Book class that stores some basic information about each Book instance:

As usual, we perform our instance property assignment in the __init__(self, title: str = None, author: str = None, page_count: int = None, publication_date: datetime.date = None) method. Aside from that, the __eq__(self, other) method is worth noting, since this is the built-in method that will be called when attempting to check equivalence between a Book instance and another object. To handle this we’re using the __dict__ built-in property as a form of comparison (though we could opt for __str__(self) comparison or otherwise).

The code we’ll be using to test some object instances starts with the check_equality(a, b) method:

Most of the code here handles outputting information to the log about the equality test. The critical line is assert a == b, "The objects ARE NOT equal.", which performs an assertion that both passed objects are equivalent to one another. The second argument of an assert statement is the failure message that is used as an argument if a failure occurs. In practical terms, this failure message argument is added to the AssertionError instance .args property, giving us an actual error message when catching the exception elsewhere in our code. Since a failed assert statement always raises an AssertionError, if execution continues past that statement we can assume the objects are equal and output as much to the log.

With everything setup we can test our assertion method by creating a couple Book instances, the_stand and the_stand_2:

Passing both Book instances to check_equality(a, b) produces the following output:

As we can logically assume since all the arguments passed to both Book initializers were identical, our assert statement succeeded and we see the confirmation output in the log.

However, let’s see what happens if we try a second test with two slightly different Book objects, where one instance wasn’t passed a publication_date argument during initialization:

As you can probably guess, these two Book objects are not considered equal, since their underlying __dict__ properties are different from one another. Consequently, our assert statement fails and raises an AssertionError in the output:

Airbrake’s robust error monitoring software provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake’s state of the art web dashboard ensures you receive round-the-clock status updates on your application’s health and error rates. No matter what you’re working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize exception parameters, while giving you complete control of the active error filter system, so you only gather the errors that matter most.

Check out Airbrake’s error monitoring software today and see for yourself why so many of the world’s best engineering teams use Airbrake to revolutionize their exception handling practices!