On Thursday, 7 August 2014 at 15:21:14 UTC, H. S. Teoh via
Digitalmars-d wrote:
Huh, what? I thought asserts in pre-conditions are
non-recoverable,
because they imply that user code has broken the contract
governing the use of that function.
I suspect this new treatment of assert will affect the way that
people check for errors. For example, in the server apps I
write, I don't always want a hard stop of the entire process if I
detect a logic error because it provides a potential attack
vector for a user to bring down an entire service. As soon as
someone determines that a particular request kills all
transactions on a process...
This isn't just paranoia in a new direction either. The servers
I work on are literally under constant attack by hackers.
Largely botnets trying to crack passwords, but not exclusively
that. And so I might want to at least drain out all pending
requests before halting the process, or I might want to just kill
the transaction that detected the logic error and leave
everything running, assuming I can be sure that the potential
collateral damage is local to the transaction (which is typically
the case).
Longer term, this new treatment of assert will probably encourage
better program design which guarantees memory isolation by
multiprocessing. I favor this direction, but messaging has a way
to go first. And by extension, I do think that memory sharing in
a language that allows direct memory access is the real risk.
That a logic error might cause a thread / process to generate an
invalid message is not an issue any more than it would be an
issue to call a function with bad parameters. In both cases, the
implication is that the caller is in an invalid state, not the
callee. So long as there is no vector through which one context
can alter the data accessed by another context without proper
validation, the corruption cannot spread.
