On Thursday, November 28, 2013 18:28:55 Gary Willoughby wrote: > On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote: > > I don't know what is the proper way to handle this but current > > situation is clearly worth a bugzilla entry. It is just weird. > > Maybe this is intended behaviour to handle testing AssertErrors > in unit tests? How else could you test them.
I wouldn't. I honestly don't think that testing contracts is an appropriate thing to do, much as I can see why you might want to do it. If you're passing something to a functon which violates that function's contract, then you're violating its contract, which is technically undefined behavior as far as DbC is concerned. I think that testing that the correct exception is being thrown from a function makes sense, because in that case, it's something that the function is suppose to handle. But per DbC, a function should never have to deal with input which violates its contract and it's undefined behavior if it's given such input. So, you really need to make sure that you never give it incorrect input. The assertions in an in block are just insurance so that you can catch bugs when you screw it up. But if you're absolutely determined to validate your contracts, I'd suggest simply creating another function which does the validation and then calling that from within the in block. e.g. bool validateFoo(int i, int j) { return i <= j; } auto foo(int i, int j) in { asser(validateFoo(i, j)); } body { ... } And using a validator function has the advantage that you can make it available to callers of your function if you want to so that they can validate the input. Or if you want to, validateFoo could be purely for the contract and just assert rather than putting the assertion in the in block (though that's a _lot_ less efficient when unit testing, as thrown exceptions are very, very slow). But either way, by putting the actual validation code outside of the in block, you can test the validation code. - Jonathan M Davis