ReRe: why isolated components

Joachim Durchholz joachim.durchholz@REDACTED
Fri Aug 22 12:14:23 CEST 2003

Laszlo Varga wrote:
> thanks for the "answer". Right, isolation reduces the (possible) complexity,
> 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.

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).
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. However, my Erlang 
experience is *very* limited, so please consider the latter just an 
uninformed opinion.


More information about the erlang-questions mailing list