testtools breaks if a string exception is raised

[Martin Packman]

Testtools deliberately lets string exceptions from test cases propagate, rather than cause failures:

    except Exception:
        # Note that bare exceptions are not caught, so raised strings will
        # escape: but they are deprecated anyway.

Given that, though deprecated, such things are not completely unheard of, see <lp:~jelmer/bzr/no-string-exc> for instance, it might be worth rethinking this. Bazaar at least has various bits of core infrastruture that prefer the test suite not to randomly fall over when it has issues.

[Martin Packman (gz)]

E
======================================================================
ERROR: test_string_exception (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python24\testtools_string_exception.py", line 5, in test_string_exception
    raise "string exception"
string exception

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)

[Martin Packman (gz)]

.Traceback (most recent call last):
  File "C:\Python24\testtools_string_exception.py", line 9, in ?
    unittest.main()
  File "C:\Python24\lib\unittest.py", line 759, in __init__
    self.runTests()
  File "C:\Python24\lib\unittest.py", line 796, in runTests
    result = self.testRunner.run(self.test)
  File "C:\Python24\lib\unittest.py", line 696, in run
    test(result)
  File "C:\Python24\lib\unittest.py", line 428, in __call__
    return self.run(*args, **kwds)
  File "C:\Python24\lib\unittest.py", line 424, in run
    test(result)
  File "C:\Python24\lib\unittest.py", line 428, in __call__
    return self.run(*args, **kwds)
  File "C:\Python24\lib\unittest.py", line 424, in run
    test(result)
  File "C:\Python24\lib\unittest.py", line 281, in __call__
    return self.run(*args, **kwds)
  File "C:\Python24\Lib\site-packages\testtools\testcase.py", line 331, in run
    return self.__RunTest(self, self.exception_handlers).run(result)
  File "C:\Python24\Lib\site-packages\testtools\runtest.py", line 63, in run
    return self._run_one(actual_result)
  File "C:\Python24\Lib\site-packages\testtools\runtest.py", line 77, in _run_one
    return self._run_prepared_result(ExtendedToOriginalDecorator(result))
  File "C:\Python24\Lib\site-packages\testtools\runtest.py", line 88, in _run_prepared_result
    self._run_core()
  File "C:\Python24\Lib\site-packages\testtools\runtest.py", line 104, in _run_core
    if self.exception_caught == self._run_user(
  File "C:\Python24\Lib\site-packages\testtools\runtest.py", line 128, in _run_user
    return fn(*args)
  File "C:\Python24\Lib\site-packages\testtools\testcase.py", line 368, in _run_test_method
    testMethod()
  File "C:\Python24\testtools_string_exception.py", line 5, in test_nonascii_exception
    raise "string exception"
string exception

[Robert Collins (lifeless)]

Well, they are pretty evil, and there isn't any good syntactic sugar to handle them. Its true that bzr had one hanging around, but do you know anyone that:
 - has string exceptions
 - wants them
 - doesn't care about python2.6 ?

[Martin Packman (gz)]

Putting up a branch with a minimal fix for this, not including better handling of errors from inside exception __str__ methods which would need an equivalent fix in Python 3 traceback._some_str and is really another issue anyway.