ReRe: why isolated components
Fri Aug 22 16:33:52 CEST 2003
> > > but is that the motivation for the wrapper project?
> > Well, *that* is another issue.
> > I don't know Joe's thoughts on the subject, but my impression is that
> > it's about coping with failures.
> > If a subroutine crashes, or if it just detects an abnormal condition and
> > logs it, this is behaviour that punches right through to the top levels
> > of the application. The "let it crash" philosophy of Erlang says: if a
> > component fails, let if fail, and don't burden the caller (or service
> > requester or whatever you name it) with analysis of the crash details,
> > just tell it that the request failed.
> > The toplevel may be unable to cope with the situation, but then passing
> > up crash details will introduce lots of coupling just for the rare case
> > of a crash - the resulting design mess just isn't worth the benefits.
Processes that fail if they can't do what they are supposed to do
are called "fail-stop" - this is how the Tandem computer was designed.
I recentely read the amazingly good:
author = "Jim Gray",
title = "Why do computers stop and what can be done about it?",
type = "Technical Report",
number = "85.7",
institution = "Tandem Computers",
year = 1985
It was like reading a description of Erlang.
One way to describe Erlang and OTP is "It's just like the tandem - only in
software instead of hardware"
> > Other languages handle this via exceptions.
> > Eiffel got this right: Eiffel exceptions are unsuitable for passing up
> > information on a crash (apart from diagnostic information that helps
> > programmers and debuggers; there's no channel for passing up information
> > that would help the top-level to analyze the error).
Yes - as well as isolation you need, what schneider calls
> > Java and C++ got it wrong: they make it all too easy to pass up
> > information that allows the caller to continue. The net result being
> > that exceptions create an additional, quite tight coupling between low
> > and high levels of the system. (It's no good if the top-level of a
> > system tries to handle an InternetConnectionFailure exception just
> > because an Internet resource wasn't available ten call levels below it...)
> > Erlang's idea is to separate the layers of processing into separate
> > processes, and to let the process crash. The advantage is that this
> > quite nicely handles any memory leaks that might occur on lower levels
> > (even garbage-collected languages can leak memory: when calling out into
> > C, or when accumulating larger and larger structures).
> > I consider it a disadvantage that this interleaves the issues of crash
> > protection and asynchronous message passing.
I beg to differ :-)
> However, my Erlang
> > experience is *very* limited, so please consider the latter just an
> > uninformed opinion.
> > HTH
> > Jo
More information about the erlang-questions