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