I want to make a decorator which will catch exceptions and adequately logged their.
def logger(foo):
try:
print foo()
except Exception as e:
print e
#logger
def d():
return 2/2
if __name__ == '__main__':
d()
Thats right i think, but then I run it and I have an exception like this:
1
Traceback (most recent call last):
File "log.py", line 14, in <module>
d()
TypeError: 'NoneType' object is not callable
Why interpreter tells me that the function has None type, but call it and print answer?
Your decorator needs to return a function, but it's not returning anything, hence the 'TypeError: 'NoneType' object is not callable'. You can implement it this way:
def logger(foo):
def fn():
try:
print foo()
except Exception as e:
print e
return fn
Check out This question for a good example of how to write/use a decorator.
logger as you have defined, does not return a value. All such functions can be thought of as returning None. You have not defined your decorator correctly. It should look more like this:
def logger(foo):
def _logger(foo):
try:
print foo()
except Exception as e:
print e
return _logger
...but keep in mind that this loses a great deal of information, catches and swallows a great deal of exceptions, and also swallows any return values from the foo function so decorated. While you probably do something different in your production code than what you have shown here, the important thing is that the decorator function must itself return a function that can be called (_logger in my example).
Related
I think this should be a bit tricky but somehow feasible, but I need help.
I'd like to execute two functions from within my main() func.
I'd like to be able to catch exceptions from the two separately, but still being able to execute both and get the result of at least one of them if the other raises an exception.
Let's say I have:
def foo():
raise TypeError
def bar():
return 'bar'
If I do (adapted from here):
def multiple_exceptions(flist):
for f in flist:
try:
return f()
except:
continue
def main():
multiple_exceptions([foo, bar])
main()
main() would return 'bar', but I'd like to be able to still throw the exception from foo() after all. This way, I would still have the result of one of my functions and the information on the error occurred in the other.
You can capture and store the exceptions using 'as', e.g.:
try:
raise Exception('I am an error!')
print('The poster messed up error-handling code here.') #should not be displayed
except Exception as Somename:
print(Somename.message)
# you'll see the error message displayed as a normal print result;
# you could do print(stuff, file=sys.stderr) to print it like an error without aborting
print('Code here still works, the function did not abort despite the error above')
...or you can do:
except Exception as Somename:
do_stuff()
raise Somename
Thanks for the comments.
I solved by doing this:
def multiple_exceptions(flist):
exceptions = []
for f in flist:
try:
f()
except Exception as e:
exceptions.append(e.message)
continue
return exceptions
def main():
multiple_exceptions([foo, bar])
error_messages = main() # list of e.messages occurred (to be raised whenever I want)
Then I can raise my exception like e.g. raise Exception(error_messages[0]) (I only care about the first in this case let's say).
New-ish to Python but I'm trying to understand this slice of code:
with pytest.raises(ValueError):
group_adjust(vals, [grps_1, grps_2], weights)
After reading this tutorial on with, I understand pytest.raises() returns a context manager that sets up and cleans up things before and after group_adjust() is called. I also understand that group_adjust() should raise a ValueError if something goes wrong.
How does pytest "react" when a ValueError is raised? AFAIK, there's only setting up and cleaning up so I'm not sure how it catches the exception. The end goal for this is to understand the benefits of having pytest as a context manager.
__exit__ magic function accepts exception_type, exception_value and traceback parameters:
In [5]: class RaisesContext:
...: def __enter__(self):
...: return self
...: def __exit__(self, exception_type, exception_value, traceback):
...: print('Exception type:', exception_type)
...: print('Exception value:', exception_value)
...: print('Traceback:', traceback)
...: return True
...:
In [6]: with RaisesContext():
...: raise ValueError('Something went wrong')
...:
Exception type: <class 'ValueError'>
Exception value: Something went wrong
Traceback: <traceback object at 0x7fd92f4a2c48>
They are None, if the with block ends normally:
In [7]: with RaisesContext():
...: pass
...:
Exception type: None
Exception value: None
Traceback: None
The with construct calls two "magic" methods, __enter__ and __exit__ at the beginning and end of the code block, respectively. Thus,
with foo:
x = 1
Can be read as:
foo.__enter__()
x = 1
foo.__exit__()
Except that, as soon mentioned in hir answer, __exit__ is called with details on why the code block is exiting: if an exception, what kind, otherwise None.
So the object returned by pytest.raises(TYPE) has been configured to expect an exception of TYPE. The __exit__ method compares the parameter it receives declaring the actual (if any) exception with the internal data member it has storing the expected exception type, and then decides to pass or fail the test.
I'm not completely sure about pytest but any context manager is passed 3 arguments on its exit, the exc_type, Excepton and Traceback, if no exception was raise all three are none and if the exit returns True then the exception is suppressed as well,
better explained here: https://docs.python.org/2/reference/datamodel.html#object.exit
so if I want to make a simple handler that will show the traceback without stopping the program I could do this:
import traceback
class VerboseTry:
def __enter__(self):
pass
def __exit__(self,exc_type,error,trace):
if exc_type:
traceback.print_exception(exc_type,error,trace)
return True
def f(depth=4):
"""this will (needlessly) raise an error with several iterations to the traceback"""
if depth==0:
int("this is going to fail")
else:
return f(depth-1)
print("starting")
with VerboseTry():
f()
print("got to end")
to see the error that was raised without halting the program.
So, I have the most trivial in the world example. This is my class to be tested:
# My_Class.py
class My_Class(object):
#staticmethod
def doit(name, params):
try:
raise Exception("This is my error message")
except Exception:
print("Exception: I raised Exception")
And this is the tester itself:
# test.py
import unittest
from My_Class import My_Class
class Test_MyClass(unittest.TestCase):
def setUp(self):
self.my_class = My_Class()
def test_my_class(self):
name = "Abrakadabra"
params = {}
self.assertRaises(Exception, self.my_class.doit, name, params)
And this is what I see in the console, when I'm running my test.py:
$ nosetests test.py
F
======================================================================
FAIL: test_my_class (test.Test_MyClass)
----------------------------------------------------------------------
Traceback (most recent call last):
File ....
nose.proxy.AssertionError: Exception not raised by doit
-------------------- >> begin captured stdout << ---------------------
Exception: I raised Exception
--------------------- >> end captured stdout << ----------------------
----------------------------------------------------------------------
Ran 1 test in 0.001s
FAILED (failures=1)
It is reaaly iteresting, because it is controversial. On the one hand the test says that "Exception not raised by doit", but one line below it clearly prints out a message from the Exception block. So, what I'm doing wrong here??? Thanks!
To directly answer your question, the reason why you are getting that message is because with this assertion:
self.assertRaises(Exception, self.my_class.doit, name, params)
You are testing to make sure an exception was raised. But your try/except suppresses this. If you actually remove your try/except your test will in fact pass, because now your method will raise.
Since you do not want to do this, what you should be doing instead is testing the behaviour of your method when an exception is raised. Ultimately, you want to make sure that your print method is called in your except. I have put together an example below to help understand this.
Keeping in mind what #user2357112 mentioned, which is very important to keep in mind when unittesting, here is an example to help expand on that to provide a practical use for what you are trying to do:
Let us just put together some method:
def some_method():
pass
We will now put this in to your staticmethod you defined as such:
# My_Class.py
class My_Class(object):
#staticmethod
def doit(name, params):
try:
some_method()
except Exception:
print("Exception: I raised Exception")
So now, when it comes to your unittesting, you want to test the behaviour of your method doit. With that in mind, what you will do in this case, is test that some_method will raise an exception and you will validate how your doit method behaves to that exception being raised.
At this point, I suggest taking a look at the documentation behind unittest and mock to get more familiar with what you can do with your testing, but here is an example using mock patching to test the behaviour of your code if an exception is being raised:
#patch('builtins.print')
#patch('__main__.some_method')
def test_my_class(self, m_some_method, m_print):
name = "Abrakadabra"
params = {}
# have the side_effect raise the exception when some_method is called in doit
m_some_method.side_effect = Exception()
self.my_class.doit(name, params)
# check to make sure you caught the exception by checking print was called
self.assertEqual(m_print.call_count, 1)
When you put it all together, the following is functional code that I ran on my end that you can play around with to understand what is happening:
def some_method():
pass
# My_Class.py
class My_Class(object):
#staticmethod
def doit(name, params):
try:
some_method()
except Exception:
print("Exception: I raised Exception")
# test.py
import unittest
from mock import patch
class Test_MyClass(unittest.TestCase):
def setUp(self):
self.my_class = My_Class()
#patch('builtins.print')
#patch('__main__.some_method')
def test_my_class(self, m_some_method, m_print):
name = "Abrakadabra"
params = {}
m_some_method.side_effect = Exception()
self.my_class.doit(name, params)
self.assertEqual(m_print.call_count, 1)
if __name__ == '__main__':
unittest.main()
assertRaises is an assertion about the function's visible behavior, not its internals. It asserts that the stated exception passes out of the function. Any exceptions that are handled inside the function are not assertRaises's concern.
assertRaises failed since there was actually no exception raised. Well, it was raised but handled with except inside the doit() method. The problem is here:
try:
raise Exception("This is my error message")
except Exception:
print("Exception: I raised Exception")
You are raising an exception and then catching it without re-raising. From a caller (assertRaises is the caller in your case) perspective, no errors were thrown during the function call. Re-raising an exception allows a caller to handle an exception as well. Put a raise after the print:
try:
raise Exception("This is my error message")
except Exception:
print("Exception: I raised Exception")
raise # re-raising
Also see Handling Exceptions.
I tried to define my own exception class in python 2.7, deriving from BaseException.
class NestedCommentException(BaseException):
"""
Exception for nested comments
"""
def __init__(self, file_path, list_lines):
self.file_path = file_path
self.list_lines = list_lines
def __repr__(self):
return self.__str__()
def __str__(self):
return 'File {0} contains nested comments at lines {1}'.format(self.file_path, ', '.join(self.list_lines))
But when throwing it, it cannot be printed: raise NestedCommentException(file_path, list_lines) triggers
Traceback (most recent call last):
File "D:\DATA\FP12210\My Documents\Outils\SVN\05_impl\2_tools\svn_tag_setup.py", line 85, in <module>
tag_checks()
File "D:\DATA\FP12210\My Documents\Outils\SVN\05_impl\2_tools\svn_tag_setup.py", line 66, in tag_checks
check_nested_comments(ddl_path)
File "D:\DATA\FP12210\My Documents\Outils\SVN\05_impl\2_tools\svn_tag_setup.py", line 54, in check_nested_comments
raise NestedCommentException(file_path, list_lines)
NestedCommentException: <unprintable NestedCommentException object>
Can you please explain why this happens, even if I defined __str__ and __repr__ methods ?
TL;DR
When you see this thing, it basically means that some kind of exception has been raised in __str__() of your object. So unless the problem is trivial enough to see at the first sight (e.g. forgotten "%s"), either
wrap the __str__ body in a try/except clause as Anurag advices, or
instantiate your exception and call the __str__ (or any methods you may have
overridden) manually, outside the traceback module, so that you get the full
description of the exception.
Analysis
Actually this <unprintable MyException object> can come from various functions in traceback module, which, when trying to get a string (i.e. "printable") version of a value (exception), it
calls str() on it, and if anything goes wrong,
tries to treat it as unicode and convert it to ASCII, and if still anything
goes wrong
simply prints the above representation.
Responsible code (same in 2.6 and 2.7):
def _some_str(value):
try:
return str(value)
except Exception:
pass
try:
value = unicode(value)
return value.encode("ascii", "backslashreplace")
except Exception:
pass
return '<unprintable %s object>' % type(value).__name__
As you can see, any exceptions coming from the str() call or the unicode.encode() call are ceased in the process and only the "cryptic" representation is given.
Note on traceback module vs. Python interpreter
Contrary to what traceback documentation tells us:
It exactly mimics the behavior of the Python interpreter when it prints
a stack trace.
the representation given by Python interpreter is slightly different here. As opposed to the "unprintable" message, the interpreter would simply display the name of the exception, ceasing any actual exceptions as well.
Here is a simple script that demonstrates all three approaches: leaving the exception to Python interpreter, using traceback module, or calling the function by hand.
#!/usr/bin/python
import sys, traceback
class Boom(Exception):
def __init__(self, foo, bar, baz):
self.foo, self.bar, self.baz = foo, bar, baz
def __str__(self):
return ("boom! foo: %s, bar: %s, baz: " # ouch! forgot an %s!
% (self.foo, self.bar, self.baz))
def goBoom(): raise Boom(foo='FOO', bar='BAR', baz='BAZ')
if __name__ == "__main__":
if sys.argv[1].startswith("i"):
goBoom()
# __main__.Boom
elif sys.argv[1].startswith("t"):
try: goBoom()
except: traceback.print_exc(file=sys.stdout)
# Boom: <unprintable Boom object>
elif sys.argv[1].startswith("m"):
e = Boom(foo='FOO', bar='BAR', baz='BAZ')
e.__str__()
# TypeError: not all arguments converted during string formatting
else: pass
My guess is that you have unicode in file_path or list_lines variables dues to which it is not being printed on a console without unicode capabilities.
or any other exception in __str__ can cause such strange behavior, best way is to catch exception and see whats is happening, use debugger too
def __str__(self):
try:
s = 'File {0} contains nested comments at lines {1}'.format(self.file_path, ', '.join(self.list_lines))
except Exception,e:
print "-----",type(e),e
return s
How do I test my parameter if it will raise an exception without actually raising it, using try and except?
class MyClass:
def function(parameter):
pass
parameter is an ambiguous function that may raise 1 or more of any exception, for example:
parameter = pow("5", 5)
A TypeError is raised as soon as the function is called and before the function can execute its statements.
In a comment to another answer you said: "parameter is another function; take for example: parameter = pow("5", 5) which raises a TypeError, but it could be any type of function and any type of exception."
If you want to catch the exeption inside your function you have to call the paramenter (which I'm assuming is callable) inside that function:
def function(callable, args=()):
try:
callable(*args)
except:
print('Ops!')
Example:
>>> function(pow, args=("5", 5))
Ops!
This is if you really need to call your "paramenter" inside the function. Otherwise your should manage its behaviour outside, maybe with something like:
>>> try:
... param = pow('5', 5)
... except:
... param = 10
...
>>> param
10
>>> function(param)
In this example, to raise an exception is pow not function, so it's a good practice to separate the the two different call, and wrap with a try-except statement the code that might fail.
From what I can understand, you want to handle the exceptions raised and also inspect what sort of errors were raised for further inspection? Here is one way of doing it.
class Foo(object):
def find_errors(arg):
errors = []
try:
# do something
except TypeError as e:
errors.append(e)
# handle exception somehow
except ValueError as e:
errors.append(e)
# handle exception somehow
# and so on ...
finally:
pass #something here
return errors, ans
Now you can inspect errors and find out what exceptions have been raised.
If you expect the parameter to be a certain type, you can use type(paramter) is parametertype.
For example, if you wanted to verify that 'i' is an int, run instructions if(type(i) is int):
By edit:
try:
pow("5",5)
return 0
except Exception, err:
sys.stderr.write('ERROR: %s\n' % str(err))
return 1
Perhaps what you mean is how to catch the TypeError exceptions caused by invalid function calls?
Like this:
def foo(bar):
pass
foo(1, 2)
You don't catch them in the function and certainly not in the def foo(bar): line.
It's the caller of the function that made an error so that's where you catch the exception:
try:
foo(1, 2)
except TypeError:
print('call failed')