The issue of re-raising base Exception instead of the original exception to avoid non-standard exception class constructors (like e.g. UnicodeEncodeError) could be addressed by dynamically creating a derived exception class:

def reraise(exc_info=(None, None, None), errorMsg=''):
    """Re-raise the latest exception given by exc_info tuple (as returned by
    sys.exc_info()) with additional errorMsg text.
    Exceptions with non-standard constructors get re-raised as derived
    exceptions, with recorded original error message and original traceback.
    Parameters:
        exc_info: (, , )
            tuple
        errorMsg: error message text to add to the exception error message
    """
    excClass, exc, tb = exc_info
    try:
        # re-raise original exception with added custom error message
        raise excClass, excClass("%s: %s" % (exc, errorMsg)), tb
    except TypeError:
        if excClass == TypeError:
            # original exception is TypeError, which has a standard constructor:
            # safe to re-raise this way
            raise excClass, excClass("%s: %s" % (exc, errorMsg)), tb

        # TypeError due to non-standard exception constructor 
        if issubclass(excClass, Exception):
            # raise derived exception class with added custom error message
            class CustomInfoException(excClass):
                def __init__(self, info='', args=[]):
                    self._info = info
                    excClass.__init__(self, *args)

                def __str__(self):
                    return "%s: %s" % (excClass.__str__(self), self._info)

            CustomInfoException.__name__ = excClass.__name__
            raise CustomInfoException, \
                  CustomInfoException(info=errorMsg, args=exc.args), tb
        else:
            # raise base Exception class with added original exception
            # message plus custom error message. Safe for old string exceptions.
            raise Exception, \
                  Exception("%s: %s: %s"
                            % (getattr(excClass, '__name__', excClass), exc or
                               excClass, errorMsg)), tb

As a derived class, the re-raised exception would even be caught later on if a dedicated exception handler for the original exception existed somewhere further up the call stack.

In action:

>>> a = u'\xe4'
>>> def foo(s):
 ...     try:
 ...             b = str(s)
 ...     except:
 ...             reraise(sys.exc_info(), "really common problem")
 ...
 >>> foo(a)
 Traceback (most recent call last):
   File "", line 1, in ?
   File "", line 5, in foo
   File "", line 3, in foo
 __main__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal
 not in range(128): really common problem
>>>

except Exception, exc:
    args = exc.args
    if not args:
        arg0 = ''
    else:
        arg0 = args[0]
    arg0 += ' at line %s' % lineno
    exc.args = arg0 + args[1:]
    raise

the second to last line should be

exc.args = (arg0,) + args[1:]

Here’s a slightly more worked-out example, maybe a little over-functional in style, but it’s flexible. With the prepend_exc_str function (defined later), you can do:

def prepend():
    try:
        dummy = b # throws NameError
    except Exception, exc:
        prepend_exc_str(exc, 'Message: ')
        raise
prepend()

and get the result:

Traceback (most recent call last):
  File "msg_add.py", line 44, in ?
    prepend()
  File "msg_add.py", line 31, in prepend
    dummy = b # throws NameError
NameError: Message: global name 'b' is not defined

Here’s the code, ready to change for other forms of message modification:

def prepend_str(main, str):
    return str + main

def append_str(main, str):
    return main + str

def modify_exc_str_func(func):
    def inner_func(exc, str):
        # modifies exception in-place, so no return value
        # based on original by Ian Bicking:
        # <a href="http://blog.ianbicking.org/2007/09/12/re-raising-exceptions/" rel="nofollow">http://blog.ianbicking.org/2007/09/12/re-raising-exceptions/</a>
        args = exc.args
        if not args:
            arg0 = ''
        else: arg0 = args[0]
        arg0 = func(arg0, str)
        exc.args = (arg0,) + args[1:]
    return inner_func

prepend_exc_str = modify_exc_str_func(prepend_str)
append_exc_str = modify_exc_str_func(append_str)

Traceback as an instance variable is a good start, combined with an optional ’cause exception’ instance variable would practically yield the Java solution. Well, this and support in the ‘language culture’ - making people actually use it :-)

Would the tb_next attribute of traceback objects serve this purpose?

Ross

Then again, this is exactly what you’re tackling here, teaching people how to do it right. So, all is well; but I think my confusion is excusable, since re-raising actually doesn’t necessarily imply that you’re dealing with a catastrophic failure and are going to abort without an attempt of recovery. That’s just one case. (Another case, for example, would be guarding against a specific error, trying to handle it, and having the error handling fail. I can think of more examples, but I’m sure you can do so as well.)

re: Java — I believe (maybe only in py3k…?) that the traceback object is being added as an instance variable in the exception, which will probably make this all easier, and similar to in Java.

That feature showed up in Java in the 1.4 release, I believe. It wasn’t there originally; I know, because I had to implement it myself before Java 1.4 was out. It’s also not a feature of the language, per se; it’s a feature of how the exception library classes are written. Seems to me that one could add the capability of nested, or wrapped, exceptions to Python easily enough.

It is a useful solution to the problem, because you get tracebacks for everything in the chain of nested exceptions. A little verbose at times, but a useful compromise.