Adding information to an exception?

Maybe

except Exception as e:
    raise IOError(e.message + 'happens at %s'%arg1)

You can define your own exception that inherits from another and create it’s own constructor to set value.

For example:

class MyError(Exception):
   def __init__(self, value):
     self.value = value
     Exception.__init__(self)

   def __str__(self):
     return repr(self.value)

Assuming you don’t want to or can’t modify foo(), you can do this:

try:
    raise IOError('stuff')
except Exception as e:
    if len(e.args) >= 1:
        e.args = (e.args[0] + ' happens',) + e.args[1:]
    raise

This is indeed the only solution here that solves the problem in Python 3 without an ugly and confusing “During handling of the above exception, another exception occurred” message.

In case the re-raising line should be added to the stack trace, writing raise e instead of raise will do the trick.

One handy approach that I used is to use class attribute as storage for details, as class attribute is accessible both from class object and class instance:

class CustomError(Exception):
    def __init__(self, details: Dict):
        self.details = details

Then in your code:

raise CustomError({'data': 5})

And when catching an error:

except CustomError as e:
    # Do whatever you want with the exception instance
    print(e.details)

Unlike previous answers, this works in the face of exceptions with really bad __str__.
It does modify the type however, in order to factor out unhelpful __str__ implementations.

I’d still like to find an additional improvement that doesn’t modify the type.

from contextlib import contextmanager
@contextmanager
def helpful_info():
    try:
        yield
    except Exception as e:
        class CloneException(Exception): pass
        CloneException.__name__ = type(e).__name__
        CloneException.__module___ = type(e).__module__
        helpful_message = '%snnhelpful info!' % e
        import sys
        raise CloneException, helpful_message, sys.exc_traceback


class BadException(Exception):
    def __str__(self):
        return 'wat.'

with helpful_info():
    raise BadException('fooooo')

The original traceback and type (name) are preserved.

Traceback (most recent call last):
  File "re_raise.py", line 20, in <module>
    raise BadException('fooooo')
  File "/usr/lib64/python2.6/contextlib.py", line 34, in __exit__
    self.gen.throw(type, value, traceback)
  File "re_raise.py", line 5, in helpful_info
    yield
  File "re_raise.py", line 20, in <module>
    raise BadException('fooooo')
__main__.BadException: wat.

helpful info!

I will provide a snippet of code that I use often whenever I want to add extra info to an exception. I works both in Python 2.7 and 3.6.

import sys
import traceback

try:
    a = 1
    b = 1j

    # The line below raises an exception because
    # we cannot compare int to complex.
    m = max(a, b)  

except Exception as ex:
    # I create my  informational message for debugging:
    msg = "a=%r, b=%r" % (a, b)

    # Gather the information from the original exception:
    exc_type, exc_value, exc_traceback = sys.exc_info()

    # Format the original exception for a nice printout:
    traceback_string = ''.join(traceback.format_exception(
        exc_type, exc_value, exc_traceback))

    # Re-raise a new exception of the same class as the original one, 
    # using my custom message and the original traceback:
    raise type(ex)("%snnORIGINAL TRACEBACK:nn%sn" % (msg, traceback_string))

The code above results in the following output:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-6-09b74752c60d> in <module>()
     14     raise type(ex)(
     15         "%snnORIGINAL TRACEBACK:nn%sn" %
---> 16         (msg, traceback_string))

TypeError: a=1, b=1j

ORIGINAL TRACEBACK:

Traceback (most recent call last):
  File "<ipython-input-6-09b74752c60d>", line 7, in <module>
    m = max(a, b)  # Cannot compare int to complex
TypeError: no ordering relation is defined for complex numbers

I know this deviates a little from the example provided in the question, but nevertheless I hope someone finds it useful.

In case you came here searching for a solution for Python 3 the manual says:

When raising a new exception (rather than using a bare raise to re-raise the exception currently being handled), the implicit exception context can be supplemented with an explicit cause by using from with raise:

raise new_exc from original_exc

Example:

try:
    return [permission() for permission in self.permission_classes]
except TypeError as e:
    raise TypeError("Make sure your view's 'permission_classes' are iterable. "
                    "If you use '()' to generate a set with a single element "
                    "make sure that there is a comma behind the one (element,).") from e

Which looks like this in the end:

2017-09-06 16:50:14,797 [ERROR] django.request: Internal Server Error: /v1/sendEmail/
Traceback (most recent call last):
File "venv/lib/python3.4/site-packages/rest_framework/views.py", line 275, in get_permissions
    return [permission() for permission in self.permission_classes]
TypeError: 'type' object is not iterable 

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
    # Traceback removed...
TypeError: Make sure your view's Permission_classes are iterable. If 
     you use parens () to generate a set with a single element make 
     sure that there is a (comma,) behind the one element.

Turning a totally nondescript TypeError into a nice message with hints towards a solution without messing up the original Exception.

I don’t like all the given answers so far. They are still too verbose imho. In either code and message output.

All i want to have is the stacktrace pointing to the source exception, no exception stuff in between, so no creation of new exceptions, just re-raising the original with all the relevant stack frame states in it, that led there.

Steve Howard gave a nice answer which i want to extend, no, reduce … to python 3 only.

except Exception as e:
    e.args = ("Some failure state", *e.args)
    raise

The only new thing is the parameter expansion/unpacking which makes it small and easy enough for me to use.

Try it:

foo = None

try:
    try:
        state = "bar"
        foo.append(state)

    except Exception as e:
        e.args = ("Appending '"+state+"' failed", *e.args)
        raise

    print(foo[0]) # would raise too

except Exception as e:
    e.args = ("print(foo) failed: " + str(foo), *e.args)
    raise

This will give you:

Traceback (most recent call last):
  File "test.py", line 6, in <module>
    foo.append(state)
AttributeError: ('print(foo) failed: None', "Appending 'bar' failed", "'NoneType' object has no attribute 'append'")

A simple pretty-print could be something like

print("n".join( "-"*i+" "+j for i,j in enumerate(e.args)))

This is my implementation, to use it as a context manager and optionally add extra message to exception:

from typing import Optional, Type
from types import TracebackType

class _addInfoOnException():
    def __init__(self, info: str = ""):
        self.info = info

    def __enter__(self):
        return

    def __exit__(self,
                 exc_type: Optional[Type[BaseException]],
                 exc_val: BaseException,  # Optional, but not None if exc_type is not None
                 exc_tb: TracebackType):  # Optional, but not None if exc_type is not None
        if exc_type:
            if self.info:
                newMsg = f"{self.info}ntLow level error: "
                if len(exc_val.args) == 0:
                    exc_val.args = (self.info, )
                elif len(exc_val.args) == 1:
                    exc_val.args = (f"{newMsg}{exc_val.args[0]}", )
                elif len(exc_val.args) > 0:
                    exc_val.args = (f"{newMsg}{exc_val.args[0]}", exc_val.args[1:])
            raise

Usage:

def main():
    try:
        raise Exception("Example exception msg")
    except Exception:
        traceback.print_exc()
        print("nn")

    try:
        with _addInfoOnException():
            raise Exception("Example exception msg, no extra info")
    except Exception:
        traceback.print_exc()
        print("nn")

    try:
        with _addInfoOnException("Some extra info!"):
            raise Exception("Example exception msg")
    except Exception:
        traceback.print_exc()
        print("nn")


if __name__ == "__main__":
    main()

This would resolve in such traceback:

Traceback (most recent call last):
  File "<...>VSCodeDevWorkspacetestis.py", line 40, in main
    raise Exception("Example exception msg")
Exception: Example exception msg



Traceback (most recent call last):
  File "<...>VSCodeDevWorkspacetestis.py", line 47, in main
    raise Exception("Example exception msg, no extra info")
  File "<...>VSCodeDevWorkspacetestis.py", line 47, in main
    raise Exception("Example exception msg, no extra info")
Exception: Example exception msg, no extra info



Traceback (most recent call last):
  File "<...>VSCodeDevWorkspacetestis.py", line 54, in main
    raise Exception("Example exception msg")
  File "<...>VSCodeDevWorkspacetestis.py", line 54, in main
    raise Exception("Example exception msg")
Exception: Some extra info!
        Low level error: Example exception msg

With PEP 678 (Python 3.11) adding notes to exceptions is natively supported:

try:
  raise TypeError('bad type')
except Exception as e:
  e.add_note('Add some information')
  raise

Rendered as:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: bad type
Add some information

I was hopping it could replace Steve Howard solution, Unfortunately, it does not give user any control on how to format the final exception (e.g. can’t add a note before the exception like: 'Error in fn: {original_exc}')

If you want more control on the traceback, you can use https://github.com/google/etils:

from etils import epy

with epy.maybe_reraise('Error in fn: '):
  fn()

Or:

try:
  fn()
except Exception as e:
  epy.reraise(e, suffix='. Did you mean y ?')

Here’s what I use for personal projects (I’m sure there’s ample reason not to do this in production code):

try:
    #something hazardous
except Exception as e:
    insightful_message = "shouldn't have done that"
    amended_args = tuple([f'{e.args[0]}n{insightful_message}', *e.args[1:]])
    e.args = amended_args
    raise

The code (1) intercepts the error; (2) creates a copy of the error’s .args property, which is a tuple that is assumed to include an error message at index 0, achieved using a list comprehension; (3) appends a line break and a custom message to the error message; (4) appends any additional items of .args to the copy using
unpacking; (5) converts the copy to a tuple; and finally (6) replaces .args with the amended copy.

Most of these operations are to circumvent the immutability of the .args tuple.

I use in my codes:

try:
    a=1
    b=0
    c=a/b

except:
    raise Exception(f"can't divide {a} with {b}")

output:

---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)
~AppDataLocalTemp/ipykernel_11708/1469673756.py in <module>
      3     b=0
----> 4     c=a/b
      5 

ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Exception                                 Traceback (most recent call last)
~AppDataLocalTemp/ipykernel_11708/1469673756.py in <module>
      5 
      6 except Exception:
----> 7     raise Exception(f"can't divide {a} with {b}")

Exception: can't divide 1 with 0