[issue24134] assertRaises can behave differently

[Magnus Carlsson]

New submission from Magnus Carlsson:

Hi

I have a little issue with the current assertRaises implementation. It seems 
that it might produce a little different results depending on how you use it.

self.assertRaises(IOError, None)

will not produce the same result as:

with self.assertRaises(IOError):
None()

In the first case everything will be fine due to the fact that assertRaises 
will actually return a context if the second callable parameters is None. The 
second case will throw a TypeError 'NoneType' object is not callable.

I don't use None directly, but replace it with a variable of unknown state and 
you get a little hole where problems can creep in. In my case I was testing 
function decorators and that they should raise some exceptions on special 
cases. It turned our that I forgot to return the decorator and instead got the 
default None. But my tests didn't warn me about that.

Bottom line is that if I use the first assertRaises(Exception, callable) I 
can't rely on it to check that the callable is actually something callable.

I do see that there is a benefit of the context way, but in my opinion current 
implementation will allow problems to go undetected. 

My solution to this would be to rename the context variant into something 
different:
with self.assertRaisesContext(Exception):
do_something()

A side note on this is that reverting back to the original behavior would allow 
you to reevaluate issue9587 for returning the actual exception.

--
components: Library (Lib)
messages: 242658
nosy: magnusc
priority: normal
severity: normal
status: open
title: assertRaises can behave differently
type: behavior
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24134
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24134] assertRaises can behave differently

[Magnus Carlsson]

Magnus Carlsson added the comment:

The solution to that is to always have a test that your decorator actually 
returns a function. That's what I do.

Yes, I agree that with more tests I would have found the problem, but sometimes 
you forget things. And to me I want the tests to fail by default or for cases 
that are unspecified.

I think the sentinel solution would come a long way of solving both the issue 
that I reported but still keep the context solution intact.

Out of curiosity, would it be a solution to have the sentinel be a real 
function?

def _sentinel():
pass

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24134
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com