Program logic bugs vs input/environmental errors

[Brad Roberts via Digitalmars-d]

On 10/3/2014 10:00 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 29/09/14 02:09, Walter Bright via Digitalmars-d wrote:
>> If the program has entered an unknown state, its behavior from then on
>> cannot be
>> predictable. There's nothing I or D can do about that. D cannot
>> officially
>> endorse such a practice, though D being a systems programming language
>> it will
>> let you do what you want.
>>
>> I would not even consider such a practice for a program that is in
>> charge of
>> anything that could result in injury, death, property damage, security
>> breaches,
>> etc.
>
> I think I should clarify that I'm not asking you to say "I endorse
> catching Errors".  Your point about systems responsible for the safety
> of people or property is very well made, and I'm fully in agreement with
> you about this.
>
> What I'm asking you to consider is a use-case, one that I picked quite
> carefully.  Without assuming anything about how the system is
> architected, if we have a telephone exchange, and an Error occurs in the
> handling of a single call, it seems to me fairly unarguable that it's
> essential to avoid this bringing down everyone else's call with it.
> That's not simply a matter of convenience -- it's a matter of safety,
> because those calls might include emergency calls, urgent business
> communications, or any number of other circumstances where dropping
> someone's call might have severe negative consequences.
>
> As I'm sure you realize, I also picked that particular use-case because
> it's one where there is a well-known technological solution -- Erlang --
> which has as a key feature its ability to isolate different parts of the
> program, and to deal with errors by bringing down the local process
> where the error occurred, rather than the whole system.  This is an
> approach which is seriously battle-tested in production.
>
> As I said, I'm not asking you to endorse catching Errors in threads, or
> other gross simplifications of Erlang's approach.  What I'm interested
> in are your thoughts on how we might approach resolving the requirement
> for this kind of stability and localization of error-handling with the
> tools that D provides.
>
> I don't mind if you say to me "That's your problem" (which it certainly
> is:-), but I'd like it to be clear that it _is_ a problem, and one that
> it's important for D to address, given its strong standing in the
> development of super-high-connectivity server applications.

The part of Walter's point that is either deliberately overlooked or 
somewhat misunderstood here is the notion of a fault domain.  In a 
typical unix or windows based environment, it's a process.  A fault 
within the process yields the aborting of the process but not all 
processes.  Erlang introduces within it's execution model a concept of a 
process within the higher level notion of the os level process.  Within 
the erlang runtime it's individual processes run independently and can 
each fail independently.  The erlang runtime guarantees a higher level 
of separation than a typical threaded java or c++ application.  An error 
within the erlang runtime itself would justifiably cause the entire 
system to be halted.  Just as within an airplane, to use Walter's 
favorite analogy, the seat entertainment system is physically and 
logically separated from flight control systems thus a fault within the 
former has no impact on the latter.

So, where you have domains which must not impact each other, you reach 
for tools that allow complete separation such that faults within one 
CANNOT impact the other.  You don't leave room for 'might not'.

Later,
Brad