Nick Coghlan wrote: > Taking an existing function such as assertRaises and going "hey, we > aren't using the return value from this, wouldn't it be really > convenient if it told us the exact exception it actually caught?" > doesn't cause any problems for existing code, and makes it much easier > to write tests that need to check additional details about the exception > that is raised (e.g. to check that the correct error code is captured > and reported for things like OSError). > > The essence of the function remains unchanged - you're still asserting > that a particular exception is raised. Returning the actual exception > object that was caught is merely a convenience that makes a lot of sense. I'm not sure I understand... If "a particular exception is raised", every thing is good and there is no error to report. ie... the code being tested did the right thing. If it does not raise the particular desired exception, isn't either a failureException raised or someother exception, which is caught by the unittest test runner. In that case the assertRaises method never gets a chance to return anything. If this is correct, then the exception needs to be caught and passed out via the failureException, and not the returned value. Ron
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4