Python Exception Class Hierarchy

Python Exception Handling – FloatingPointError

Today we get started with our in-depth Python Exception Handling series by looking at the FloatingPointError. As with most programming languages, the FloatingPointError in Python indicates that something has gone wrong with a floating point calculation. However, unlike most other languages, Python will not raise a FloatingPointError by default. The ability to do so must be implemented by including the fpectl module when building your local Python environment.

In this article we’ll explore the FloatingPointError by first looking at where it resides in the overall Python Exception Class Hierarchy. We’ll also go over how the fpectl module can be enabled, and how doing so can allow the raising of FloatingPointErrors in your own code. 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.

When Should You Use It?

As discussed in the introduction, before a FloatingPointError can even appear you’ll need to make sure your local Python build includes the fpectl module. Since this module is not included with most Python builds by default, you’d likely have had to explicitly build your Python with it if desired. Adding the fpectl module to can be accomplished by using the --with-fpectl flag when compiling Python. Going through the compilation process of Python is well beyond the scope of this article, but once fpectl is an included module, you can start testing the FloatingPointError.

For our example code we’re not doing anything spectacular. In fact, the FloatingPointError is effectively raised in situations where other ArithmeticErrors would normally appear, except that you’re using floating point numbers and the fpectl module is enabled. For example, you might raise a FloatingPointError where you’d normally get a ZeroDivisionError by attempting to divide by zero using a floating point value.

We’ve created a few simple testing methods starting with test_floating_point():

Executing this code works as expected, performing the floating point calculation and rounding the result to four decimal places before outputting the result to our log:

Now, let’s step away from using a floating point value and use regular integers while attempting to divide by zero:

This raises an unexpected ZeroDivisionException since, even though fpectl is enabled, we aren’t using a floating point value in our calculation:

Finally, let’s try the same division by zero while using floating point values:

As you might suspect, this raises a FloatingPointError for us:

There we have the basics of using FloatingPointErrors. However, before you jump into adding the fpectl module to your Python to distinguish between FloatingPointErrors and normal ArithmeticErrors, there are a number of caveats and cautions to be aware of. The IEEE 754 standard for floating point arithmetic defines a number of universal standards for the formatting, rounding, allowed operations, and exception handling practices of floating point numbers. However, your code must be explicitly told to capture IEEE 754 exceptions in the form of SIGFPE signals generated by the local processor. Consequently, while Python is configured to do so via the fpectl module, many other custom scripts/applications are not.

The other major consideration is that use of the fpectl module is generally discouraged, in large part because it is not thread safe. Thread safe applications (that is, most properly developed Python applications) allow data structures to be safely shared between multiple threads without fear of one thread manipulating or altering some data that another thread is using (or where another thread sees different data). However, using the fpectl module means your floating point data is no longer thread safe, which could cause major issues in multithreaded applications. To be on the safe side, it’s generally recommended that you avoid fpectl and use another form of application logic to check for arithmetic errors.

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!