Adding information to an exception? [duplicate]

Question

I want to achieve something like this:

def foo():
   try:
       raise IOError('Stuff ')
   except:
       raise

def bar(arg1):
    try:
       foo()
    except Exception as e:
       e.message = e.message + 'happens at %s' % arg1
       raise

bar('arg1')

Traceback...
  IOError('Stuff Happens at arg1')

But what I get is:

Traceback..
  IOError('Stuff')

Any clues as to how to achieve this? How to do it both in Python 2 and 3?

Imelda

While looking for documentation for the Exception message attribute I found this SO question, BaseException.message deprecated in Python 2.6, which seems to indicate its use is now discouraged (and why it's not in the docs). – Soapberry

sadly, that link doesn't seem to work anymore. – Hymanhymen

@MichaelScottCuthbert here's a good alternative: itmaybeahack.com/book/python-2.6/html/p02/… – Weil

Here's a really good explanation of what the status of the message attribute is and its relationship to the args attribute and PEP 352. It's from the free book Building Skills in Python by Steven F. Lott. – Soapberry

Related (not dupe): Re-raise exception with a different type and message, preserving existing information – Islean

Answer 1

I'd do it like this so changing its type in foo() won't require also changing it in bar().

def foo():
    try:
        raise IOError('Stuff')
    except:
        raise

def bar(arg1):
    try:
        foo()
    except Exception as e:
        raise type(e)(e.message + ' happens at %s' % arg1)

bar('arg1')

---

Traceback (most recent call last):
  File "test.py", line 13, in <module>
    bar('arg1')
  File "test.py", line 11, in bar
    raise type(e)(e.message + ' happens at %s' % arg1)
IOError: Stuff happens at arg1

Update 1

Here's a slight modification that preserves the original traceback:

...
def bar(arg1):
    try:
        foo()
    except Exception as e:
        import sys
        raise type(e), type(e)(e.message +
                               ' happens at %s' % arg1), sys.exc_info()[2]

bar('arg1')

---

Traceback (most recent call last):
  File "test.py", line 16, in <module>
    bar('arg1')
  File "test.py", line 11, in bar
    foo()
  File "test.py", line 5, in foo
    raise IOError('Stuff')
IOError: Stuff happens at arg1

Update 2

For Python 3.x, the code in my first update is syntactically incorrect plus the idea of having a message attribute on BaseException was retracted in a change to PEP 352 on 2012-05-16 (my first update was posted on 2012-03-12). So currently, in Python 3.5.2 anyway, you'd need to do something along these lines to preserve the traceback and not hardcode the type of exception in function bar(). Also note that there will be the line:

During handling of the above exception, another exception occurred:

in the traceback messages displayed.

# for Python 3.x
...
def bar(arg1):
    try:
        foo()
    except Exception as e:
        import sys
        raise type(e)(str(e) +
                      ' happens at %s' % arg1).with_traceback(sys.exc_info()[2])

bar('arg1')

Update 3

A commenter asked if there was a way that would work in both Python 2 and 3. Although the answer might seem to be "No" due to the syntax differences, there is a way around that by using a helper function like reraise() in the six add-on module. So, if you'd rather not use the library for some reason, below is a simplified standalone version.

Note too, that since the exception is reraised within the reraise() function, that will appear in whatever traceback is raised, but the final result is what you want.

import sys

if sys.version_info.major < 3:  # Python 2?
    # Using exec avoids a SyntaxError in Python 3.
    exec("""def reraise(exc_type, exc_value, exc_traceback=None):
                raise exc_type, exc_value, exc_traceback""")
else:
    def reraise(exc_type, exc_value, exc_traceback=None):
        if exc_value is None:
            exc_value = exc_type()
        if exc_value.__traceback__ is not exc_traceback:
            raise exc_value.with_traceback(exc_traceback)
        raise exc_value

def foo():
    try:
        raise IOError('Stuff')
    except:
        raise

def bar(arg1):
    try:
       foo()
    except Exception as e:
        reraise(type(e), type(e)(str(e) +
                                 ' happens at %s' % arg1), sys.exc_info()[2])

bar('arg1')

Soapberry

That loses the backtrace, kind of defeating the point of adding information to an existing exception. Also, it doesn't work exceptions with ctor that takes >1 arguments (the type is something you cannot control from the place where you catch the exception). – Ulick

@Václav: It's fairly easy to prevent losing the backtrace -- as shown in the update I added. While this still doesn't handle every conceivable exception, it does work for cases similar to what was shown in the OP's question. – Soapberry

This isn't quite right. If type(e) overrides __str__, you may get undesirable results. Also note that the second argument is passed to the constructor given by the first argument, which yields a somewhat nonsensical type(e)(type(e)(e.message). Thirdly, e.message is deprecated in favor of e.args[0]. – Tengdin

@martineau: I just wanted to update your link to Exceptions chapter of the free book "Building Skills in Python - A Programmer's Introduction to Python" by Steven F. Lott – Nachison

@bukzor: I don't think it's fair to fault my answer because PEP 352 was changed after it posted. Regardless, I've added another update to address the issues you pointed out. – Soapberry

This answer would be better if you'd attempt to consolidate your updates to one answer. There is an edit history for those interested in your previous incomplete or outdated answers, but in truth that's unlikely to occur. – Tengdin

@bukzor: I don't agree. The first update is still valid for at least Python 2.6 - 2.7.4, so having it as well as update 2 for those using still seems worthwhile. – Soapberry

so, there isn't a portable way that works in both Python 2 and 3? – Neurocoele

@Soapberry What's the purpose of importing inside the except block? Is this to save memory by only importing when necessary? – Forced

@joshsvoss: Just to make it lazily imported (delayed until actually needed) -- ideally exceptions are cases not conforming to the general rule -- however moving it to the top of the function or module would be fine, too. – Soapberry

@elias: You might be able to write something that worked in both Python 2 and 3 by using the six module's reraise() function. – Soapberry

@elias: See Update 3 in answer. – Soapberry

I found that e.g. UnicodeDecodeError fails with function takes exactly 5 arguments. The answer by Steve Howard contains a useful hint; raise type(e)(stuff, *e.args[1:]).with_traceback(...) which then might as well of course use the from form from the answer by Chris. – Beekeeper

Answer 2

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.

Caracul

This is the best solution, since the resulting exception points back to the original cause, supply more detail. – Amidase

is there any solution that we can add some message but still not raise a new exception? I mean just extend the message of the exception instance. – Lilith

Yaa~~ it works, but it feels like something that should not be done to me. The message is stored in e.args, but that is a Tuple, so it cannot be changed. So first copy args into a list, then modify it, then copy it back as a Tuple: args = list(e.args) args[0] = 'bar' e.args = tuple(args) – Caracul

@edcSam, I found this to work for a custom exception: def __init__(self, message): super().__init__("some prefix: " + message) – Whitson

This does raise two exceptions, each with their own traceback, that essentially points to the same place in the code. – Macassar

Answer 3

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.

Larisa

but in this case if the exception changes in foo, I have to change bar as well right.? – Imelda

If you catch Exception (edited above), you can catch any standard library exception (as well as those that inherit from Exception and call Exception.__init__). – Larisa

Clever, but assumes that e.args is initially a one-tuple, which may not always be the case, and doesn't add the " at %s'%arg1" part. – Soapberry

The first part is correct, the second isn't terribly relevant (you can always put that back in, I was lazy typing). I wouldn't use any strategy that attempts to modify exceptions in the first place. – Larisa

to be more complete/cooperative, include the other parts of the original tuple: e.args = ('mynewstr' + e.args[0],) + e.args[1:] – Heft

@nmz787 This is the best solution for Python 3 in fact. What exactly is your error? – Lowry

@Heft and martineau I incorporated your suggestions into an edit. – Lowry

Note that this will fail when catching a PermissionError: TypeError: can only concatenate str (not "int") to str – Elbe

Answer 4

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 ?')

Tolerate

PEP 678 was just accepted – Christianize

This is a nice solution. Which version of Python do we expect will bring support for it? – Macassar

It's new in Python 3.11: docs.python.org/3/library/… – Olympus

Answer 5

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)))

Snoopy

This has the downside that the outer frames are not part of the stack trace. – Rehearse

Answer 6

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)

Mich

Not really useful since the OP is requesting that the details be printed as part of the stack trace when the original exception is thrown and not caught. – Ossieossietzky

I think the solution is good. But the description is not true. Class attributes are copied to instances when you instantiate them. So when you modify the attribute "details", of the instance, the class attribute still will be None. Anyway we want this behavior here. – Sapling

Answer 7

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)("%s\n\nORIGINAL TRACEBACK:\n\n%s\n" % (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         "%s\n\nORIGINAL TRACEBACK:\n\n%s\n" %
---> 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.

Hudibrastic

Answer 8

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)

Argueta

Doesn't address need to change/append something to the message of the original exception (but could be fixed, I think). – Soapberry

Answer 9

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 = '%s\n\nhelpful 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!

Tengdin

Answer 10

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.

Christianize

Answer 11

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}\n\tLow 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("\n\n")

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

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


if __name__ == "__main__":
    main()

This would resolve in such traceback:

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



Traceback (most recent call last):
  File "<...>\VSCodeDevWorkspace\testis.py", line 47, in main
    raise Exception("Example exception msg, no extra info")
  File "<...>\VSCodeDevWorkspace\testis.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 "<...>\VSCodeDevWorkspace\testis.py", line 54, in main
    raise Exception("Example exception msg")
  File "<...>\VSCodeDevWorkspace\testis.py", line 54, in main
    raise Exception("Example exception msg")
Exception: Some extra info!
        Low level error: Example exception msg

Pathological

Answer 12

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)
~\AppData\Local\Temp/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)
~\AppData\Local\Temp/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

Meng

Answer 13

Maybe

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

Indreetloire