Error Handling and Logging

To make Error Handling work in the backend and the frontend (without exceptions in the backend breaking the frontend), we use the python logging module (documentation, introduction) and the Django messages framework (documentation). Exceptions get send as messages to the frontend and displayed there and logged in the console.

Usage:

This is how to use it in a calculation method:

from django.contrib import messages

def by_filter_something():
    # ...
    try:
        # your code that could cause an Exception e goes here
    except ATypeOfError as e:
        msg = "A step by a filter something method does not support ..., consider doing ... instead or some other descriptive message."
        level = messages.ERROR
        trace = str(e)
        aTypeOfErrorMessage = dict(level=level, msg=msg, trace=trace)

• level: Determines the priority, currently implemented are: ERROR, WARNING and INFO (all levels but the DEBUG level that map directly between Django messages framework and logging module). Ideally, our styling will reflect the different levels. It should be possible to add new levels if needed (see django docu, this post, don't forget the mapping in constants/logging.py).
• msg is the message that gets printed in the console and shown in the frontend.
• trace (optional) is the python Exception trace to make it easier to understand what caused the Exception.
• one message is a dict of level, msg and trace

In an appropriate location return the occurred messages as a list as part of the dict:

return intensity_df, dict(
            filtered_protein_list=None,
            anomaly_df=None,
            messages=[aTypeOfErrorMessage],
        )

Do not forget to test this behavior e.g. by asserting that certain keywords are in the messages output. For an example in the code see the outlier detection methods.

Console Logging

PROTzilla provides a unified logger with identical formatting for the Django-Webserver logging as well as PROTzillas logging. The styling is defined by the ProtzillaLoggingHandler-Class defined in protzilla/constants/logging.

PROTzilla

It can be imported and used anywhere within PROTzilla by from protzilla.constants.logging import logger and calling logger.debug(), logger.info(), logger.warning(), logger.error(), logger.critical().

The logger is defined and configured at the bottom of the file logging.py as logger; by default with level INFO. Therefore, all log-messages with severity INFO and higher will be output. As a consequence, debug-logging can (and to a degree should (readable to programmers after you)) be left in the code. To adjust the logging-level modify protzilla_logging_level to your liking.

UI

The Django-logger also uses the ProtzillaLoggingHandler-Class. It's logging is specified in ui/main/settings.py::LOGGING. It, as well, is configured with level INFO. This can be adjusted in ui/main/settings.py::LOGGING but only set the severity for Django itself. If you want PROTzilla to be more verbose, refere to the section Console Logging::PROTzilla in this same file.