 Defensive programming in erlang
started 3/10/2003; 3:06:20 AM - last post 3/14/2003; 4:21:12 AM
|
|
Ehud Lamm - Defensive programming in erlang 
3/10/2003; 3:06:20 AM (reads: 1653, responses: 5)
|
|
| Defensive programming in erlang |
|
A nice exposition.
Not different from what you'd expect to find, if you are familiar with languages with exceptions.
But there are some nuances due to erlang's problem domain and concurrency semantics.
Posted to Software-Eng by Ehud Lamm on 3/10/03; 3:08:44 AM
|
|
|
|
Darius Bacon - Re: Defensive programming in erlang
3/10/2003; 11:12:02 AM (reads: 825, responses: 0)
|
|
|
Nice. The earliest espousal I've seen of that "let it crash" school of defensive programming was in Leo Brodie's _Thinking Forth_ -- he quoted a Forth programmer saying of the language, "Its fragility is its strength."
|
|
Luke Gorrie - Re: Defensive programming in erlang
3/11/2003; 6:56:23 AM (reads: 730, responses: 0)
|
|
|
NB: In Erlang, "let it crash" really means "let it crash (but always have a recovery plan.)" Is there a similar subtitle to the Forth philosophy?
I think there are a lot of flavours of "let it crash." e.g. Bertrand Meyer seems to say "Let it crash (but only during development - only release when its Absolutely Correct.)", which is very different to Erlang's philosophy of tollerating programming errors in production systems (on the assumption that they are inevitable.)
How 'bout Forth?
|
|
Todd Coram - Re: Defensive programming in erlang
3/11/2003; 7:11:16 AM (reads: 735, responses: 0)
|
|
|
In Forth there is no tolerance for "programming errors in production systems". In a traditional (classic?) Forth system: you crash, you burn, you die (and take the machine with you).
The strength of Forth is that it doesn't get in your way. No pesky abstractions to cloud the interaction between programmer and machine.
This means that for a lot of Forth development systems, programmer error during development results in cold restarting the machine.
Forth has zero tolerance for crashes. If it shares anything with Erlang, it's the focus on solving real-world problems and matching the language to the problem domain.
I'd rather see Forth control my microwave, car engine, etc than C/C++/Java.
The more I learn about Erlang, I'd rather see it control my phone network, messaging servers, etc than C/C++/Java.
|
|
Darius Bacon - Re: Defensive programming in erlang
3/12/2003; 4:48:44 PM (reads: 639, responses: 0)
|
|
|
Luke, it depends on the application -- in embedded systems I've read about they have a monitor that gets control after a crash, plus a watchdog timer. Obviously lower-level than Erlang. :) The philosophy I've worked with has been more like Bertrand Meyer's fail-fast during development.
|
|
Luke Gorrie - Re: Defensive programming in erlang
3/14/2003; 4:21:12 AM (reads: 617, responses: 0)
|
|
|
Darius - this more coarse-grained stuff is very interesting too :-)
In our appliance boxes we do similar things incase the Erlang system totally dies (e.g. repeatedly crashes until it decides enough is enough.) If the Erlang program's unix process crashes, a tiny C program ('heart') will restart it, and (I think) if that fails often enough it will trigger a reboot of the machine. We also use a Linux kernel "watchdog" mechanism for a similar purpose, but I'm not sure of its exact semantics.
Similarly, we keep two copies of the entire operating system on the box: the "previous" one and the "new" one. If you do a software upgrade that goes catastrophically wrong, it will revert back to the old image.
|
|
|
|