On 25/03/2011 20:23, spir wrote:
This logic certainly looks sensible, but I cannot understand how it should work in practice. Say I'm implementing a little set of operations on decimals. Among those, some (division, square root...) will necessarily have to check their input. According to the rationale you expose, I should use assertions, since operand will nearly never be (direct) user input, instead be products of the app's logic. Then, what happens when div gets a null denominator on a release build? In practice, the issue is not that serious since I will certainly delegate to a lower-level func which itself throws. But I could also (in theory) implement it in assembly or whatnot. My point of view is if a func has preconditions on its args, then checkings simply cannot go away. Such considerations lead me to wonder whether we should not instead use exceptions/enforce everywhere for actual func arg checking, and use asserts in unittests only. Or use them also for /temporary/ additional checkings during development (similar to unittests in fact). A special case may be about checkings that control logical values or ranges which do not prevent the func to run. Say, a.length should logically be in 1..9 -- but the func can run fine anyway. Denis
Since I started programming in D, unittests have been among the first things I write, and I am just about getting the hang of using DMD's coverage features to make sure that my tests cover every branch of my code. Recently I have been trying to write unittests without using any additional asserts, making unittests into examples of use, designed to hit every corner case while "telling a story". I don't find it quite as easy as just writing asserts, but it is a half step toward writing decent documentation, (something I often fail at >< ) and it makes the code to be tested easier to write.
With the iota case, I want it to use assert, not enforce. I write my test so that when it runs it hits the corner cases and if there is a problem with the arguments sent to iota then execution stops in the library code. In this scenario, I know there is something I need to fix in my code (or possibly in Phobos ^^ ). If iota instead threw an exception, I would then have to put in a try/catch or a scope() and try to recover (to do otherwise would be to duplicate code already in the library), but that doesn't fix the problem, it just masks it, so my program has gotten worse, not better!
That a compiled lib (including the Phobos lib distributed with DMD) is assert-less for performance reasons, is a quality of implementation issue, not a fault of enforce, or something it was ever intended to fix.
A...
