Re: [Python-Dev] Explicitly declaring expected exceptions for ablock
Dmitry Dvoinikov writes:
The reason for that being self-tests with lots and lots of little code snippets like this:
try: c().foo() except TypeError: pass
Paul Du Boise already responded explaining that PEP 343 probably handles the task you want. I just wanted to mention that you may need to reconsider the task. The above snippet is almost certainly incorrect. I suspect that you wanted either: try: c().foo() fail('Should have raised TypeError') except TypeError: pass # expected or perhaps this: try: c().foo() except TypeError: fail('Should not have raised TypeError') There ARE situations when you want to allow an exception (but not necessarily expect it) and do nothing when it occurs, but I don't find them all that common, and I certainly don't find them arising in unit tests. -- Michael Chermside
I suspect that you wanted either:
try: c().foo() fail('Should have raised TypeError') except TypeError: pass # expected
Right, of course I use something along these lines: try: c().foo() except TypeError: pass else: assert False, "c.foo() should have thrown TypeError" and so if foo throws anything but TypeError I get traceback, otherwise it's an assertion error and is reported as such. This is probably just one of the many possible wording of the same thing though. Sincerely, Dmitry Dvoinikov http://www.targeted.org/ --- Original message follows ---
Dmitry Dvoinikov writes:
The reason for that being self-tests with lots and lots of little code snippets like this:
try: c().foo() except TypeError: pass
Paul Du Boise already responded explaining that PEP 343 probably handles the task you want. I just wanted to mention that you may need to reconsider the task. The above snippet is almost certainly incorrect. I suspect that you wanted either:
try: c().foo() fail('Should have raised TypeError') except TypeError: pass # expected
or perhaps this:
try: c().foo() except TypeError: fail('Should not have raised TypeError')
There ARE situations when you want to allow an exception (but not necessarily expect it) and do nothing when it occurs, but I don't find them all that common, and I certainly don't find them arising in unit tests.
-- Michael Chermside
try: c().foo() except TypeError: pass else: assert False, "c.foo() should have thrown TypeError"
In fact, the above code actually expects foo to throw particular exception, not exactly the same as the original requirement. More of expect TypeError: c().foo() and still can be implemented under PEP 343, that's what I meant under "more flexible". Sincerely, Dmitry Dvoinikov http://www.targeted.org/ --- Original message follows ---
I suspect that you wanted either:
try: c().foo() fail('Should have raised TypeError') except TypeError: pass # expected
Right, of course I use something along these lines:
try: c().foo() except TypeError: pass else: assert False, "c.foo() should have thrown TypeError"
and so if foo throws anything but TypeError I get traceback, otherwise it's an assertion error and is reported as such. This is probably just one of the many possible wording of the same thing though.
Sincerely, Dmitry Dvoinikov http://www.targeted.org/
--- Original message follows ---
Dmitry Dvoinikov writes:
The reason for that being self-tests with lots and lots of little code snippets like this:
try: c().foo() except TypeError: pass
Paul Du Boise already responded explaining that PEP 343 probably handles the task you want. I just wanted to mention that you may need to reconsider the task. The above snippet is almost certainly incorrect. I suspect that you wanted either:
try: c().foo() fail('Should have raised TypeError') except TypeError: pass # expected
or perhaps this:
try: c().foo() except TypeError: fail('Should not have raised TypeError')
There ARE situations when you want to allow an exception (but not necessarily expect it) and do nothing when it occurs, but I don't find them all that common, and I certainly don't find them arising in unit tests.
-- Michael Chermside
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/dmitry%40targeted.org
participants (2)
-
Dmitry Dvoinikov -
Michael Chermside