Handling Certain Exception Classes

A simple exception-handling __exit__ function may simply check to see if the exception is an instance of a particular exception class, perform whatever exception handling is necessary, and return True (or return False) if it gets any other exception class.

class HandleValueError(object):
    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_instance, traceback):
        # Return True if there is no exception.
        if not exc_type:
            return True

        # If this is a ValueError, note that it is being handled and
        # return True.
        if issubclass(exc_type, ValueError):
            print('Handling ValueError: %s' % exc_instance)
            return True

        # Propagate anything else.
        return False

If you use this context manager and raise ValueError inside the block, you see that it prints and then suppresses the exception.

>>> with HandleValueError():
...     raise ValueError('Wrong value.')
...
Handling ValueError: Wrong value.

Similarly, if you use this context manager but raise a different class of exception (such as TypeError, instead), it will bubble and you will still get your traceback.

>>> with HandleValueError():
...     raise TypeError('Wrong type.')
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: Wrong type.

By itself, this does not have a whole lot of value. After all, this is really just a substitute for a much more straightforward try clause.

try:
    [do something]
except ValueError as exc_instance:
    print('Handling ValueError: %s' % exc_instance)

One way that the context manager can be valuable is when the work that must be done in the except clause is both non-trivial and must be repeated in multiple places throughout the application. The context manager encapsulates not only the except clause, but also its body.

Excluding Subclasses

There is also a little more flexibility in how the class or instance check is done. For example, suppose that you want to catch a given class of exception, but explicitly not its subclasses. You cannot do that in a traditional except block (nor should you be able to), but a context manager is able to address such an edge case, as shown here:

class ValueErrorSubclass(ValueError):
    pass


class HandleValueError(object):
    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_instance, traceback):
        # Return True if there is no exception.
        if not exc_type:
            return True

        # If this is a ValueError (but not a ValueError subclass),
        # note that it is being handled and return True.
        if exc_type == ValueError:
            print('Handling ValueError: %s' % exc_instance)
            return True

        # Propagate anything else.
        return False

Note that the HandleValueError context manager has changed slightly now. It checks its type using == rather than the more traditional issubclass check that the previous example used. This means that although it will handle ValueError as before, it will not handle a ValueError subclass such as the ValueErrorSubclass defined previously:

>>> with HandleValueError():
...     raise ValueErrorSubclass('foo bar baz')
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
__main__.ValueErrorSubclass: foo bar baz

Attribute-Based Exception Handling

Similarly, a context manager might decide whether to handle an exception based on not the type of the exception (which is what an except clause must do), but rather based on an attribute of the exception.

Consider the following function designed to run shell commands conveniently, and use an exception class that is designed to be raised in response to shell errors:

import subprocess


class ShellException(Exception):
    def __init__(self, code, stdout='', stderr=''):
        self.code = code
        self.stdout = stdout
        self.stderr = stderr

    def __str__(self):
        return 'exit code %d - %s' % (self.code, self.stderr)


def run_command(command):
    # Run the command and wait for it to complete.
    proc = subprocess.Popen(command.split(' '), stdout=subprocess.PIPE,
                                                stderr=subprocess.PIPE)
    proc.wait()

    # Get the stdout and stderr from the shell.
    stdout, stderr = proc.communicate()

    # Sanity check: If the shell returned a non-zero exit status, raise an
    # exception.
    if proc.returncode > 0:
        raise ShellException(proc.returncode, stdout, stderr)

    # Return stdout.
    return stdout

Such a function (and exception class) is very easy to use. The following is an attempt to rm a bogus file:

run_command('rm bogusfile')

Running this will generate the ShellException traceback as expected.

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 11, in run_command
__main__.ShellException: exit code 1 - rm: bogusfile: No such file or directory

What happens when it comes time to handle these exceptions? Handling any generic ShellException is easy, but imagine a situation where you receive a ShellException but only want to handle a particular exit code. A context manager is one possible way to approach this.

For example, say that you want to remove a file, but you are okay with a situation where the file was already removed. (For the purpose of this example, ignore that os.remove exists.) In this case, you would be fine with a return code of 0, which indicates successful removal of the file, as well as a return code of 1, which indicates that the file was already absent. On the other hand, an exit code of 64 is still problematic, because this would indicate a usage error of some kind. This should still be raised.

Here is a context manager that would allow some ShellException instances based on their code:

class AcceptableErrorCodes(object):
    def __init__(self, *error_codes):
        self.error_codes = error_codes

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_instance, traceback):
        # Sanity check: If this is not an exceptional situation, then just
        # be done.
        if not exc_type:
            return True

        # Sanity check: If this is anything other than a ShellException,
        # then we do not actually know what to do with it.
        if not issubclass(exc_type, ShellException):
            return False

        # Return True if and only if the ShellException has a code that
        # matches one of the codes on our error_codes list.
        return exc_instance.code in self.error_codes

This example code actually introduces a new pattern. The context manager is given the error codes that it should allow when the context manager is initiated. In this case, AcceptableErrorCodes takes any number of integers as arguments, and those are used to determine which error codes are actually acceptable.

If you want to attempt to remove a non-existent file when using the AcceptableErrorCodes context manager, it will work without incident.

>>> with AcceptableErrorCodes(1):
...     run_command('rm bogusfile')
...

What this context manager will not do, however, is just blindly swallow up every ShellException it gets. Consider the following case where you actually use rm incorrectly:

>>> with AcceptableErrorCodes(1):
...     # -m is not a switch available to rm (at least in Mac OS X).
...     run_command('rm -m bogusfile')
...
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
  File "<stdin>", line 11, in run_command
__main__.ShellException: exit code 64 - rm: illegal option -- m
usage: rm [-f | -i] [-dPRrvW] file ...
       unlink file

So, why did this cause a traceback? Because the exit code was 64 (on Mac OS X; this may vary based on the exact operating system you are using), and you told the context manager that the only acceptable erratic exit code was 1. Therefore, __exit__ returned False, and the exception was bubbled as usual.