Rollbar is Capturing and Logging All Python Exceptions

Using Rollbar: Capturing and Logging All Python Exceptions


· · · ·

I recently wrote an article about tracking user exceptions using Rollbar. For the article, I implemented an experiment using Python. While I think Rollbar is a fantastic tool, I also think that in some ways developers could take a better approach than inserting a call to rollbar.report_exc_info in the except block. This method only traps exceptions you are expecting to throw and ignores unintended exceptions. In addition, if the code is not in a try … except block, then the exception does not get reported to your Rollbar account.

Fortunately, there is another solution in Python for globally capturing exceptions. In this article, I’ll take a look at the problems that this approach solves, then explain how to implement it.

First, Some Problems

So let’s take a look at some simple example code. Granted, it is silly, but it makes the point:

Every try … except block will have to have a call to sys.exc_info and a call to Rollbar to report the exception. This ends up littering logging code throughout your code base. While many developers may be fine with this, I find it gets in the way of reading the logic of the code.

Our above code will only phone home to Rollbar if there is an AttributeError or Type error. If another type of error is thrown, the exception is not sent to Rollbar. Consider the following code:

For the sake of the example, the class is sabotaged with a NameError in place of a legitimate reason to raise an exception. If we create an instance of SampleClass and access its msg property with our print_message function above, a NameError will be raised. However, no exception will be reported to Rollbar.

This implies that every time it is determined by the developers, a method or function should throw an exception not listed in the except block, and the code will have to be refactored to catch the new exception so it will be reported to Rollbar. This is an error-prone process we would wish to avoid.

Consider also that any code not wrapped in a try … except block will never report to Rollbar at all. This could possibly lead to developers overusing try … except in Python or implementing a bare except in hopes of catching everything.

A Solution

Fortunately, Python’s sys module provides sys.excepthook which allows developers to inject custom behavior into Python’s exception handling.

Here is an example of how it could be used:

By replacing the default sys.excepthook with a custom functionality to log exceptions to Rollbar, we get a single place in our code, which will be called when any exception is raised. Note that sys also provides the excepthook dunder, which can be called to trigger the default behavior of sys.excepthook.

Let’s revisit our print_message function:

That cleans up rather nicely, and both expected and unexpected exceptions will be logged to Rollbar (rather than just the expected exceptions), while allowing developers to create custom handling for expected exceptions in the standard manner without extra code.

Further, if an exception is thrown by code not wrapped in a try … except block, it will trigger our custom behavior and log the exception to Rollbar.

In this article, we have taken a look at some of the problems with using Rollbar. We’ve looked at some of the issues around logging uncaught exceptions to Rollbar, and a possible solution.

Do you think you can beat this Sweet post?

If so, you may have what it takes to become a Sweetcode contributor... Learn More.

Daniel Avila is a Python developer/Certified Scrum Master focusing on Django applications and best practices in Python.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *