From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 13 Jun 2006 13:08:22 +0100 From: rog@vitanuova.com To: 9fans@cse.psu.edu Subject: Re: [9fans] quantity vs. quality In-Reply-To: <8ccc8ba40606121415i63c1064fi5ae59cf04fca7aa2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 69dba482-ead1-11e9-9d60-3106f5b1d025 i think this has been mentioned on the list before (otherwise i wouldn't have known to look for it) but when considering error recovery tactics, it's worth looking at http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf ("Making reliable software systems in the presence of errors") he summarises their approach to error recovery as follows: - if you can't do what you want to do, die. - let it crash. - do not program defensively. they built a telecoms switching system with a reported measured reliability of 99.9999999% following this philosophy. see section 4.3 (page 101) for details. the key is that another process gets notified of the error. he makes this useful distinction between "error" and "exception": - exceptions occur when the run-time system does not know what to do. - errors occur when the programmer does not know what to do. i would suggest that most out-of-memory conditions are best classed as errors, not exceptions.