Classifiers

Project description

This app provides integration between Python and Errordite, a centralised
error logging and management service, not unlike Sentry, but with more
functionality around the classification and management of errors.

The application is provided in the form of a standard Python logging handler.
In order to log exceptions with Errordite, you simply use logging.error or
logging.exception in your except block:

Details of the implementation are best found in the code itself - it’s fairly
self-explanatory.

Important info regarding sys.exc_info() and sys.exc_clear()

This logging handler is explicitly designed to capture and publish Python
exceptions. It is not a generic logger, and as such it relies on the use of
sys.exc_info() to determine whether there is anything to report. This can
have an unexpected effect if you are logging items as errors that have no
explicit exception attached, but where a previous exception has been swallowed.

In the example below - we are catching and swallowing the DoesNotExist error
because it’s a known code path:

try:
.. do something that raises a known error - e.g. model.DoesNotExist
except model.DoesNotExist:
.. we half expected this, so just ignore it for now

However, the exception has not been cleared, and if you call sys.exc_info()
further on it will still return the DoesNotExist error. A little further on in
our example we are logging a business exception (trying to checkout a negative
basket value) but not attaching any explicit python error:

.. continue on with the method
.. some time later
if basket_total < 0:
logger.error("Someone tried to hack our checkout.")

In this case the wrong exception (DoesNotExist) information will be recorded.

The solution to this is to call sys.exc_clear() in the except block
so that the exception is removed explicitly. The Python docs state that:

This function is only needed in only a few obscure situations.

Which suggest that this is not recommended, however, they go on to state:

These include logging and error handling systems that report information
on the last or current exception.

It is the author’s opinion that this describes our exact predicament,
and so the use of sys.exc_clear() is justified. (That said, you may also
want to investigate why you are logging errors that aren’t exceptions if
you see this situation occurring.)

Installation

The library is available at pypi as ‘errordite’, and can therefore be
installed using pip:

Configuration

In order to set up a valid ErrorditeHandler you must pass in an
Errordite API token, which you can get by signing up at http://www.errordite.com

Tests

There are tests in the package - they can be run using unittest:

$ python -m unittest errordite.tests

NB These tests do log real exceptions over the wire, so you will need to be
connected to the web to run them. You will also need to set a local environment
variable (ERRORDITE_TOKEN), which is picked up in the test suite.

If you are *nix you can pass this in on the command line:

$ ERRORDITE_TOKEN=123 python -m unittest errordite.tests

If you are on Windows you’ll need to set it up explicitly as an env var:

c:\> set ERRORDITE_TOKEN=123
c:\> python -m unittest errordite.tests

(This is a technique used to prevent having to have sensitive information in
the public repo.)