Is it possible to let an exception raise itself, in its own class instance ?
Something like this:
class Error(Exception):
def __init__(self):
if some stuff:
pass
elif some other stuff:
# re-raise myself
raise Error()
I've tried to use raise self but it returns an error ; also, I don't see any attribute to the exception class that seems to be linked to this.
Edit
If I want to do this, it is because I've attached some special methods to my Exception class, which format the error message to be printed depending of what parameters are passed to the exception. I could have done the formatting job in a separate object, but as it is only used by the exception, it seemed to me natural to attach it to the exception class itself.
You can raise an exception in the __init__ of an exception type, just like you can do so in any type’s __init__. This however will prevent the object from being created—instead, the exception is thrown.
So your original raise Error() will not be called at all, and the exception object you wanted to create there is never created. Instead, you will just get an exception because the object you created (Error) couldn’t be created.
So you lose all the information about the actual raise which you wanted to execute.
As such, no, don’t do that.
In any way this also seems to be a very odd way to do have an exception type. The exception object itself should not be dependent on any outside factors, and some stuff does appear to be something magic here. What is it you are actually trying to solve here?
What might help understanding, would be writing your raise Error() like this:
e = Error()
raise e
So you first create an exception object, and only then you actually raise it. So inside the __init__ of that type, you cannot reraise it as it has never been raised yet. But there is no need to reraise it anyway, because you are still raising it afterwards. So again: What are you trying to do? Do you want the exception object itself to be capable of preventing the raise on certain conditions (hence the pass in your code)?
Update
it is because I've attached some special methods to my Exception class, which format the error message to be printed depending of what parameters are passed to the exception.
That does not justify raising an exception in the __init__ of the type at all. You can easily format your exception message all you want without having to raise the exception in the class itself. For example:
>>> class Error (Exception):
def __init__ (self, msg, rightAligned = False, spacedOut = False):
if spacedOut:
msg = ' '.join(msg)
if rightAligned:
msg = msg.rjust(72)
Exception.__init__(self, msg)
>>> raise Error('Random message')
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
raise Error('Random message')
Error: Random message
>>> raise Error('Random message', True)
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
raise Error('Random message', True)
Error: Random message
>>> raise Error('Random message', False, True)
Traceback (most recent call last):
File "<pyshell#4>", line 1, in <module>
raise Error('Random message', False, True)
Error: R a n d o m m e s s a g e
As you can see, I can change the exception message in whatever way I want without having to raise an exception in the class.
EDIT: This answer should not have been accepted. poke's answer address the heart of the problem and presents a correct solution.
A self-raising class seems to work fine for me:
>>> class Err(Exception):
... def __init__(self):
... Exception.__init__(self, 'gulp!')
... raise self
...
>>> raise Err()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in __init__
__main__.Err: gulp!
I'm not a Python language export, so this might be some weird half-aborted class that doesn't behave itself very well. Caveat emptor.
The burning question: why would you do this? Is there some reason you don't want to use the standard Python idiom of explicitly raising the exception after constructing it?
This might solve your immediate error:
raise self.__class__
However then you have a potential for infinite recursion. what if "some other stuff" is always true?
Related
I've got a try/except clause that will either return or catch a KeyError as follows:
try:
return super().__new__(globals()[kls])
except KeyError:
raise
This will generate a stack trace when used improperly like so:
>>> g = Grid(cell='Circle')
Traceback (most recent call last):
File "<pyshell#16>", line 1, in <module>
g = Grid(cell='Circle')
File "<pyshell#1>", line 8, in __new__
return super().__new__(globals()[kls])
KeyError: 'SHPCircleGrid'
>>> g
Traceback (most recent call last):
File "<pyshell#17>", line 1, in <module>
g
NameError: name 'g' is not defined
And that is perfectly fine, however I want to "extend/modify" the message to explain to the user how to avoid this error again; i.e. go from:
KeyError: 'SHPCircleGrid'
to
KeyError: 'SHPCircleGrid'. Use 'Hex', 'Rect' or 'Tri' for cell keyword.
While maintaining the stack for the user. A generic print() in the catching portion sets g to NoneType which I would not like, so simply printing is not the way to handle this. Adding another raise KeyError('some message') prints two stacks (the "while handling exception another..." message) which is also undesired.
What is the appropriate way to handle this such that it could be extended to any additional keywords that the class instantiation may throw a KeyError for?
Can't you just achieve that by supplying your message to KeyError as such:
try:
return super().__new__(globals()[kls])
except KeyError as e:
key = "'{}'".format(*e.args)
base = "{}. Use 'Hex', 'Rect' or 'Tri' for cell keyword."
raise KeyError(base.format(key)) from None
In the module warnings (https://docs.python.org/3.5/library/warnings.html) there is the ability to raise a warning that appears to come from somewhere earlier in the stack:
warnings.warn('This is a test', stacklevel=2)
Is there an equivalent for raising errors? I know I can raise an error with an alternative traceback, but I can't create that traceback within the module since it needs to come from earlier. I imagine something like:
tb = magic_create_traceback_right_here()
raise ValueError('This is a test').with_traceback(tb.tb_next)
The reason is that I am developing a module that has a function module.check_raise that I want to raise an error that appears to originate from where the function is called. If I raise an error within the module.check_raise function, it appears to originate from within module.check_raise, which is undesired.
Also, I've tried tricks like raising a dummy exception, catching it, and passing the traceback along, but somehow the tb_next becomes None. I'm out of ideas.
Edit:
I would like the output of this minimal example (called tb2.py):
import check_raise
check_raise.raise_if_string_is_true('True')
to be only this:
Traceback (most recent call last):
File "tb2.py", line 10, in <module>
check_raise.raise_if_string_is_true(string)
RuntimeError: An exception was raised.
I can't believe I am posting this
By doing this you are going against the zen.
Special cases aren't special enough to break the rules.
But if you insist here is your magical code.
check_raise.py
import sys
import traceback
def raise_if_string_is_true(string):
if string == 'true':
#the frame that called this one
f = sys._getframe().f_back
#the most USELESS error message ever
e = RuntimeError("An exception was raised.")
#the first line of an error message
print('Traceback (most recent call last):',file=sys.stderr)
#the stack information, from f and above
traceback.print_stack(f)
#the last line of the error
print(*traceback.format_exception_only(type(e),e),
file=sys.stderr, sep="",end="")
#exit the program
#if something catches this you will cause so much confusion
raise SystemExit(1)
# SystemExit is the only exception that doesn't trigger an error message by default.
This is pure python, does not interfere with sys.excepthook and even in a try block it is not caught with except Exception: although it is caught with except:
test.py
import check_raise
check_raise.raise_if_string_is_true("true")
print("this should never be printed")
will give you the (horribly uninformative and extremely forged) traceback message you desire.
Tadhgs-MacBook-Pro:Documents Tadhg$ python3 test.py
Traceback (most recent call last):
File "test.py", line 3, in <module>
check_raise.raise_if_string_is_true("true")
RuntimeError: An exception was raised.
Tadhgs-MacBook-Pro:Documents Tadhg$
If I understand correctly, you would like the output of this minimal example:
def check_raise(function):
try:
return function()
except Exception:
raise RuntimeError('An exception was raised.')
def function():
1/0
check_raise(function)
to be only this:
Traceback (most recent call last):
File "tb2.py", line 10, in <module>
check_raise(function)
RuntimeError: An exception was raised.
In fact, it's a lot more output; there is exception chaining, which could be dealt with by handling the RuntimeError immediately, removing its __context__, and re-raising it, and there is another line of traceback for the RuntimeError itself:
File "tb2.py", line 5, in check_raise
raise RuntimeError('An exception was raised.')
As far as I can tell, it is not possible for pure Python code to substitute the traceback of an exception after it was raised; the interpreter has control of adding to it but it only exposes the current traceback whenever the exception is handled. There is no API (not even when using tracing functions) for passing your own traceback to the interpreter, and traceback objects are immutable (this is what's tackled by that Jinja hack involving C-level stuff).
So further assuming that you're interested in the shortened traceback not for further programmatic use but only for user-friendly output, your best bet will be an excepthook that controls how the traceback is printed to the console. For determining where to stop printing, a special local variable could be used (this is a bit more robust than limiting the traceback to its length minus 1 or such). This example requires Python 3.5 (for traceback.walk_tb):
import sys
import traceback
def check_raise(function):
__exclude_from_traceback_from_here__ = True
try:
return function()
except Exception:
raise RuntimeError('An exception was raised.')
def print_traceback(exc_type, exc_value, tb):
for i, (frame, lineno) in enumerate(traceback.walk_tb(tb)):
if '__exclude_from_traceback_from_here__' in frame.f_code.co_varnames:
limit = i
break
else:
limit = None
traceback.print_exception(
exc_type, exc_value, tb, limit=limit, chain=False)
sys.excepthook = print_traceback
def function():
1/0
check_raise(function)
This is the output now:
Traceback (most recent call last):
File "tb2.py", line 26, in <module>
check_raise(function)
RuntimeError: An exception was raised.
EDIT: The previous version did not provide quotes or explanations.
I suggest referring to PEP 3134 which states in the Motivation:
Sometimes it can be useful for an exception handler to intentionally
re-raise an exception, either to provide extra information or to
translate an exception to another type. The __cause__ attribute
provides an explicit way to record the direct cause of an exception.
When an Exception is raised with a __cause__ attribute the traceback message takes the form of:
Traceback (most recent call last):
<CAUSE TRACEBACK>
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
<MAIN TRACEBACK>
To my understanding this is exactly what you are trying to accomplish; clearly indicate that the reason for the error is not your module but somewhere else. If you are instead trying to omit information to the traceback like your edit suggests then the rest of this answer won't do you any good.
Just a note on syntax:
The __cause__ attribute on exception objects is always initialized
to None. It is set by a new form of the 'raise' statement:
raise EXCEPTION from CAUSE
which is equivalent to:
exc = EXCEPTION
exc.__cause__ = CAUSE
raise exc
so the bare minimum example would be something like this:
def function():
int("fail")
def check_raise(function):
try:
function()
except Exception as original_error:
err = RuntimeError("An exception was raised.")
raise err from original_error
check_raise(function)
which gives an error message like this:
Traceback (most recent call last):
File "/PATH/test.py", line 7, in check_raise
function()
File "/PATH/test.py", line 3, in function
int("fail")
ValueError: invalid literal for int() with base 10: 'fail'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/PATH/test.py", line 12, in <module>
check_raise(function)
File "/PATH/test.py", line 10, in check_raise
raise err from original_error
RuntimeError: An exception was raised.
However the first line of the cause is the statement in the try block of check_raise:
File "/PATH/test.py", line 7, in check_raise
function()
so before raising err it may (or may not) be desirable to remove the outer most traceback frame from original_error:
except Exception as original_error:
err = RuntimeError("An exception was raised.")
original_error.__traceback__ = original_error.__traceback__.tb_next
raise err from original_error
This way the only line in the traceback that appears to come from check_raise is the very last raise statement which cannot be omitted with pure python code although depending on how informative the message is you can make it very clear that your module was not the cause of the problem:
err = RuntimeError("""{0.__qualname__} encountered an error during call to {1.__module__}.{1.__name__}
the traceback for the error is shown above.""".format(function,check_raise))
The advantage to raising exception like this is that the original Traceback message is not lost when the new error is raised, which means that a very complex series of exceptions can be raised and python will still display all the relevant information correctly:
def check_raise(function):
try:
function()
except Exception as original_error:
err = RuntimeError("""{0.__qualname__} encountered an error during call to {1.__module__}.{1.__name__}
the traceback for the error is shown above.""".format(function,check_raise))
original_error.__traceback__ = original_error.__traceback__.tb_next
raise err from original_error
def test_chain():
check_raise(test)
def test():
raise ValueError
check_raise(test_chain)
gives me the following error message:
Traceback (most recent call last):
File "/Users/Tadhg/Documents/test.py", line 16, in test
raise ValueError
ValueError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/Tadhg/Documents/test.py", line 13, in test_chain
check_raise(test)
File "/Users/Tadhg/Documents/test.py", line 10, in check_raise
raise err from original_error
RuntimeError: test encountered an error during call to __main__.check_raise
the traceback for the error is shown above.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/Tadhg/Documents/test.py", line 18, in <module>
check_raise(test_chain)
File "/Users/Tadhg/Documents/test.py", line 10, in check_raise
raise err from original_error
RuntimeError: test_chain encountered an error during call to __main__.check_raise
the traceback for the error is shown above.
Yes it is long but it is significantly more informative then:
Traceback (most recent call last):
File "/Users/Tadhg/Documents/test.py", line 18, in <module>
check_raise(test_chain)
RuntimeError: An exception was raised.
not to mention that the original error is still usable even if the program doesn't end:
import traceback
def check_raise(function):
...
def fail():
raise ValueError
try:
check_raise(fail)
except RuntimeError as e:
cause = e.__cause__
print("check_raise failed because of this error:")
traceback.print_exception(type(cause), cause, cause.__traceback__)
print("and the program continues...")
I understand 'Don't do this'. On the other hand, there may be some special use cases i believe. I'm generating own errors (just deleting some defined frames...) this way
def get_traceback_with_removed_frames_by_line_string(lines):
"""In traceback call stack, it is possible to remove particular level defined by some line content.
Args:
lines (list): Line in call stack that we want to hide.
Returns:
string: String traceback ready to be printed.
"""
exc = trcbck.TracebackException(*sys.exc_info())
for i in exc.stack[:]:
if i.line in lines:
exc.stack.remove(i)
return "".join(exc.format())
I return just string.
If there is concrete function that is raising, you can add it to ignored frames.
Though have in mind, that if you hide something, somebody may not understand why is something happening...
My use case was to hide only first level - decorator from my library that was decorating all user functions in framework, so error from user side was on level 1.
I am not sure what the meaning of this error is.
This is my test:
def test_method_delete(self):
test_graph = trie_builder.Graph()
node_name = 'node_0'
test_graph.node(node_name)
# Create a node.
test_graph.delete(node_name)
# Delete the node.
self.assertNotIn(node_name, test_graph.node_list)
node_name = 'node_1'
with self.assertRaises(KeyError('ERROR: Attempt to delete non-existent node.')):
test_graph.delete(node_name)
This is my method:
def delete(self, node_name):
if node_name in self.node_list:
del self.node_list[node_name]
else:
raise(KeyError('ERROR: Attempt to delete non-existent node.'))
And this is the error:
ERROR: test_method_delete (__main__.test_class_Graph)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_trie_builder.py", line 66, in test_method_delete
test_graph.delete(node_name)
File "/Users/juliushamilton/Documents/Work/Nantomics_trie_builder/trie_builder/trie_builder.py", line 25, in delete
raise(KeyError('ERROR: Attempt to delete non-existent node.'))
KeyError: 'ERROR: Attempt to delete non-existent node.'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "test_trie_builder.py", line 66, in test_method_delete
test_graph.delete(node_name)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/case.py", line 184, in __exit__
if not issubclass(exc_type, self.expected):
TypeError: issubclass() arg 2 must be a class or tuple of classes
What could be the problem? What is 'arg2' referring to?
Have you tried passing the KeyError class (without instantiating an instance) to assertRaises? It looks like assertRaises is trying to check that the error it got is of the type of error class you gave it, but KeyError('ERROR: Attempt to delete non-existent node.') is an instance of type KeyError, not the type itself.
with self.assertRaises(KeyError):
test_graph.delete(node_name)
It looks like the docs don't make this clear:
https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertRaises, but from the stack trace your gave it looks like what it does is check that the exception it receives is a subclass of the exception class you passed to it using issubclass. issubclass can only accept a type as its second argument, so passing an instance is the error you are getting.
If you want to also check the error text you need to use assertRaisesRegexp:
https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertRaisesRegexp
What does raise do, if it's not inside a try or except clause, but simply as the last statement in the function?
def foo(self):
try:
# some code that raises an exception
except Exception as e:
pass
# notice that the "raise" is outside
raise
This example prints 1 but not 2 so it must be that the last raise statement simply raises the last thrown exception.
def foo():
try:
raise Exception()
except Exception as e:
pass
print 1
raise
print 2
if __name__ == '__main__':
foo()
Any official documentation for this type of usage pattern?
As Russell said,
A bare raise statement re-raises the last caught exception.
It doesn't matter whether this is happening in a try-except block or not. If there has been a caught exception, then calling raise will re-raise that exception. Otherwise, Python will complain that the previously caught exception is None and raise a TypeError because None is not something that can actually be raised.
As tdelaney said, it doesn't seem to make sense to do this except in an error-handling function. Personally I'd say that it doesn't even belong in an error-handling function, as the raise should still be in the except clause. Someone could use this in an attempt to execute code whether or not an error occurs, but a finally clause is the proper way to do that. Another possibility would be using this as a way to determine if an error occurred while executing the function, but there are much better ways to do that (such as returning an extra value that indicates if/where an error occurred).
A Bare raise reraises the current exception. This usually makes no sense at the end of a function, unless the function is called in an exception:
By itself, the raise is invalid and python throws its own exception
>>> def x():
... raise
>>> x()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in x
TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType
But if called within an exception block, it acts sanely
>>> try:
... int('a')
... except:
... x()
...
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
File "<stdin>", line 2, in <module>
ValueError: invalid literal for int() with base 10: 'a'
>>>
EDIT
This might be a perfectly reasonable thing to do if the function is attempting some sort of recovery. The function could fix what's broken, log a message, trigger the fire extinguishers, etc... and raise if it still thinks the system is in error.
A bare raise statement re-raises the last caught exception. https://docs.python.org/2/tutorial/errors.html#raising-exceptions
From this documentation we can read:
If no expressions are present, raise re-raises the last exception that
was active in the current scope. If no exception is active in the
current scope, a TypeError exception is raised indicating that this is
an error (if running under IDLE, a Queue.Empty exception is raised
instead).
This means that, in the case of your code, if no exception occurs within the try ... except block, then you are forcing the program to raise a TypeError exception to happen.
I had a problem like this where I needed to raise a previously caught exception outside the try/except block if my function didn't return a value. I did a bit of looking around in the sys and traceback modules, but couldn't find a good method to do this, so I just ended up storing the exception outside the block.
def foo():
caught = None
try:
raise Exception
except Exception as e:
caught = e
pass
raise caught
f = foo()
Output
Traceback (most recent call last):
line 13, in <module>
line 10, in foo
line 5, in foo
Exception
Clearly this isn't useful in the above example, but it's pretty useful if you need to try something quite a few times in a loop and re-raise. My specific need was for an HTTP request retry mechanism.
import time
def foo(key):
caught = None
for i in [1, 2, 3, 4, 5]:
try:
return d[key]
except KeyError as e:
caught = e
print(i)
time.sleep(i)
continue
raise caught
d = {"bar": "baz"}
f = foo(key="baz")
Output
1
2
3
4
5
Traceback (most recent call last):
line 19, in <module>
line 15, in foo
line 8, in foo
KeyError: 'baz'
I'm trying to catch an exception in a thread and re-raise it in the main thread:
import threading
import sys
class FailingThread(threading.Thread):
def run(self):
try:
raise ValueError('x')
except ValueError:
self.exc_info = sys.exc_info()
failingThread = FailingThread()
failingThread.start()
failingThread.join()
print failingThread.exc_info
raise failingThread.exc_info[1]
This basically works and yields the following output:
(<type 'exceptions.ValueError'>, ValueError('x',), <traceback object at 0x1004cc320>)
Traceback (most recent call last):
File "test.py", line 16, in <module>
raise failingThread.exc_info[1]
However, the source of the exception points to line 16, where the re-raise occurred. The original exception comes from line 7. How do I have to modify the main thread so that the output reads:
Traceback (most recent call last):
File "test.py", line 7, in <module>
In Python 2 you need to use all three arguments to raise:
raise failingThread.exc_info[0], failingThread.exc_info[1], failingThread.exc_info[2]
passing the traceback object in as the third argument preserves the stack.
From help('raise'):
If a third object is present and not None, it must be a traceback
object (see section The standard type hierarchy), and it is
substituted instead of the current location as the place where the
exception occurred. If the third object is present and not a
traceback object or None, a TypeError exception is raised. The
three-expression form of raise is useful to re-raise an exception
transparently in an except clause, but raise with no expressions
should be preferred if the exception to be re-raised was the most
recently active exception in the current scope.
In this particular case you cannot use the no expression version.
For Python 3 (as per the comments):
raise failingThread.exc_info[1].with_traceback(failingThread.exc_info[2])
or you can simply chain the exceptions using raise ... from ... but that raises a chained exception with the original context attached in the cause attribute and that may or may not be what you want.
This code snippet works in both python 2 & 3:
1 try:
----> 2 raise KeyError('Default key error message')
3 except KeyError as e:
4 e.args = ('Custom message when get re-raised',) #The comma is not a typo, it's there to indicate that we're replacing the tuple that e.args pointing to with another tuple that contain the custom message.
5 raise