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
