11

A common pattern in python is to catch an error in an upstream module and re-raise that error as something more useful.

try:
    config_file = open('config.ini', 'r')
except IOError:
    raise ConfigError('Give me my config, user!')

This will generate a stack trace of the form

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
__main__.ConfigError: Give me my config, user!

Is there any way to access the wrapped exception in order to generate a stack trace more like this?

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
__builtin__.IOError: File Does not exist.
Exception wrapped by:
  File "<stdin>", line 4, in <module>
__main__.ConfigError: Give me my config, user!

EDIT:

The problem i'm trying to defeat is that some 3rd party code can wrap exceptions up to 3 times and I want to be able to determine the root cause, i.e. a generic way to inspect the exception stack and determine the root cause of an exception without having to add any extra code to 3rd party modules.

Thomas
  • 11,757
  • 4
  • 41
  • 57

3 Answers3

10

This is known as Exception Chaining and is suported in Python 3.

PEP 3134: http://www.python.org/dev/peps/pep-3134/

In Python 2, the old exception is lost when you raise a new one, unless you save it in the except block.

yak
  • 8,851
  • 2
  • 29
  • 23
4

Use the traceback module. It will allow you to access the most recent traceback and store it in a string. For example,

import traceback
try:
    config_file = open('config.ini', 'r')
except OSError:
    tb = traceback.format_exc()
    raise ConfigError('Give me my config, user!',tb)

The "nested" traceback will be stored in tb and passed to ConfigError, where you can work with it however you want.

austin1howard
  • 4,815
  • 3
  • 20
  • 23
  • 1
    Also, the result of format_exc() (that is stored in tb) is just a string, which consists of exactly the same text that would be printed out if it were not in a try/except block. – austin1howard Jan 25 '12 at 03:35
  • To answer your edit, as far as I know, the format_exc function will output all available information in the traceback. If a 3rd party module "suppresses" some information in a try/except loop, you won't be able to retrieve it without modifying that *particular* try/except loop. – austin1howard Jan 25 '12 at 08:32
1

Here is an example of how to unwind PEP-3134 exception chains.

Note that due to legacy reasons some Python frameworks may not use exception chaining, but instead of wrap exceptions in their own way. For example. SQLALchemy DBABIError uses orig attribute.

class Foobar(Exception):
    pass


class Dummy(Exception):
    pass


def func1():
    raise Foobar("func1() argh")


def func2():
    try:
        func1()
    except Exception as e:
        raise Dummy("func2 vyaaarrg!") from e

try:
    func2()
except Exception as e:
    print(f"Current {e.__class__}: {e}")
    print(f"Nested {e.__cause__.__class__}:{e.__cause__}")

Prints

Current <class '__main__.Dummy'>: func2 vyaaarrg!
Nested <class '__main__.Foobar'>:func1() argh

Mikko Ohtamaa
  • 82,057
  • 50
  • 264
  • 435