assume, assert, enforce, @safe

[Sean Kelly via Digitalmars-d]

On Friday, 19 September 2014 at 13:56:14 UTC, Sean Kelly wrote:
> I suspect/hope that it won't be long before communications 
> software is held to standards similar to telephone, which will 
> require a huge adjustment on the part of programmers.  People 
> in this industry still tend to not think of things in terms of 
> 5+ "nines" of uptime for their service, despite that being the 
> expectation of their users.

Oh, just to clarify one thing though.  The typical way that a lot 
of network services work for reasons of performance is via 
asynchronous event-based models (fancy versions of the Unix 
poll() routine).  If a logic error results in a transaction 
failure and I can be sure that the scope of this error is limited 
to the state of that one transaction, I don't necessarily want to 
terminate the process as it will result in thousands of failed 
transactions.  Functional languages like Erlang tend to support 
this model really well, because a "process" is actually just a 
thread of execution in the VM.  The "process" (thread) is 
terminated and the VM soldiers on because there's no logical way 
for the state of the VM to have been corrupted.

I'm still unsure how I feel about D in this regard.  Clients will 
retry if a request fails, and so terminating the entire process 
and failing thousands of transactions would be bad but possibly 
still invisible to users.  At least unless the logic error occurs 
in a common path of execution, in which case terminating the 
entire process on a logic error becomes a potential attack vector 
to bring down the entire system.

I suspect that what I'll be doing with D is moving away from 
asserts and throwing Errors to give myself the latitude to handle 
situations in whatever manner I feel is appropriate.  I'm still 
not sure about this, but I'm leaning towards feeling that the D 
approach is possibly too draconian for multi-user systems.  
Perhaps it's possible to split each transaction off to be handled 
by a separate process (via unix domain sockets, for example, or 
IPC), but I suspect this won't scale to the degree that's needed. 
  This is how web servers used to work, for example, and I'm 
pretty sure none of them do this any more.  But I want to think 
more on the problem, as I do like the motivation behind these 
rules.