Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #25421 > unrolled thread

Re: assertraises behaviour

Started byPeter Otten <__peter__@web.de>
First post2012-07-16 17:10 +0200
Last post2012-07-16 17:10 +0200
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: assertraises behaviour Peter Otten <__peter__@web.de> - 2012-07-16 17:10 +0200

#25421 — Re: assertraises behaviour

FromPeter Otten <__peter__@web.de>
Date2012-07-16 17:10 +0200
SubjectRe: assertraises behaviour
Message-ID<mailman.2177.1342451467.4697.python-list@python.org>
andrea crotti wrote:

> 2012/7/16 Christian Heimes <lists@cheimes.de>:
>>
>> The OSError isn't catched as the code never reaches the line with "raise
>> OSError". In other words "raise OSError" is never executed as the
>> exception raised by "assert False" stops the context manager.
>>
>> You should avoid testing more than one line of code in a with
>> self.assertRaises() block.
>>
>> Christian
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
> 
> Ok now it's more clear, and normally I only test one thing in the block.
> But I find this quite counter-intuitive, because in the block I want
> to be able to run something that raises the exception I catch (and
> which I'm aware of), but if another exception is raised it *should*
> show it and fail in my opinion..

That doesn't sound like "it's clearer". Perhaps it helps if you translate 
your code into a standard try...except:

>>> class A(Exception): pass
... 
>>> class B(Exception): pass
... 
>>> try:
...     raise A
...     raise B
... except A as e:
...     print "caught %r" % e
... 
caught A()

The try block is left at the "raise A' statement" -- Python doesn't have an 
equivalent of Basic's "resume next". Therefore B (or OSError) is never 
raised.

PS: Strictly speaking your "assert False" is equivalent to 

if __debug__ and False: raise AssertionError

Therefore you *can* trigger the OSError by invoking the interpreter with the
"-O" option:

$ python -c 'assert False; raise OSError'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AssertionError
$ python -O -c 'assert False; raise OSError'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web