On 2012-03-10 17:48, Jonathan M Davis wrote:
On Saturday, March 10, 2012 16:53:42 Jacob Carlborg wrote:
On 2012-03-09 18:59, H. S. Teoh wrote:
This opens up the question of, what's the *recommended* way of writing
unittests that check for these sorts of stuff?
For example, I believe in being thorough in unit tests, so I like to use
them to verify that the complicated in-contract I just wrote actually
prevents the erroneous calls that I *think* it prevents. But if catching
AssertError's may leave the program in an undefined state, then that
pretty much invalidates any further testing past that point (the program
may appear to work when compiled with -funittest but actually fail in
release mode).
I agree, though, that catching Errors outside of unittests is a very,
very bad idea in general.
I don't see what's so bad in making AssertError an exception instead of
an error.
Then
catch(Excetion e) {}
would catch it. This would be a huge problem in normal code. Assertions are
supposed to kill the program. This is specifically mentioned in TDPL.
- Jonathan M Davis
Maybe so. But the current design is broken and need to be fixed somehow.
--
/Jacob Carlborg
