Program logic bugs vs input/environmental errors

Joseph Rushton Wakeling via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 3 10:00:21 PDT 2014


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.


More information about the Digitalmars-d mailing list