assert semantic change proposal

[Sean Kelly via Digitalmars-d]

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.