On Friday, 1 August 2014 at 19:10:34 UTC, Walter Bright wrote:
On 8/1/2014 6:12 AM, Dicebot wrote:
ok, can this be considered a good summary of using
assertions/contracts for
services where risk of entering undefined state is
unacceptable?
1) never use `assert` or contracts in actual application code,
use `enforce`
instead
2) never use `enforce` in library code unless it does actual
I/O, use contracts
instead
3) always distribute both release and debug builds of
libraries and always run
tests in both debug and release mode
Does it make sense? Your actual recommendation contradict each
other but it is
best what I was able to combine them into.
What makes me hesitate about use of enforce() is its high
runtime cost. It's not just the computation, but the call stack
above it is affected by enforce() being throwable and
allocating via the GC.
`enforce` does have overload which allows to use pre-allocated
exception instance. Or, alternatively, we may need a similar
helper wich does `if (!condition) abort()` with no interaction
with -release or optimizer.
Whatever is chosen it does seem that contracts can't be used in
application code because it is too affected by user input and is
too likely to expose hidden bugs in production.
Secondly, enforce() is about recoverable errors. Program bugs
are simply NOT recoverable errors, and I cannot recommend using
them for that purpose. I've argued for decades with people who
insist that they can write code that recovers from unknown
programming bugs.
1) one can always `enforce` with a pre-allocated Error, will
druntime handle that as expected?
2) There is certain class of applications where even programming
bugs can (and must be) considered recoverable. Network services
that don't yet have full scale high availability infrastructure
(and thus can't afford downtime of restarting the app) are quite
likely to only terminate connection fibers when programming bug
is found - it does not affect serving any other connections. It
may be fundamentally wrong but is is pragmatical working approach.
These questions are not theoretical - we regularly have
discussion about how contracts may / should be used at work with
no clear understanding / agreement so far. I am interested in
simple set of guidelines that won't turn writing every single
function in a guessing game (does a contract fit here?)
