From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <85fef4168411910cbe578f9313301080@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] same functions everywhere In-Reply-To: <3EBDBBDC.3090300@null.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-erixiuoebvqmkjuozqzwuyhsos" Date: Mon, 12 May 2003 09:19:36 -0400 Topicbox-Message-UUID: a92e4546-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-erixiuoebvqmkjuozqzwuyhsos Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I love religious arguments. In #5ESS, error handling was a large % of the code. It involved in line checks, dead man timers, separate auditing systems, and lots of code review to make sure there were no `don't care' cases. It was incredibly messy and fragile. Exceptions might have cleaned up some part of it but most of the process was trying to avoid being sloppy. Much of that could be automated through tools, path analysis, and testing. The complexity is still there with inline error handling or exception mechanisms. Separating the exception code can (but not always will) clean up the main flow. It also reduces the number of places you can 'forget' to check. Unfortunately, the further from the main flow it moves, the less likely that it will be updated when the main flow changes. This has caused us almost as many errors over time as missing an exception case. At the very least the exception catcher has to be in the scope of what its cleaning up or everything (recoverable) in the main flow has to be global. However, the important part is handling all the possible error states. The really unforseen ones (except for the odd nil pointer reference or divide by zero) don't throw exceptions. In #5ESS, the auditing code was the mechanism for these kinds of errors. The auditing code continually scanned the state of switch boards, processes, and memory to make sure states didn't exist that were considered 'impossible'. Of course this meant enumerating forseen states. If you stepped outside of the forseen, it was time for action (reset the switch, kill processes, switch to another processor, ...). This is a really hard way to program and not something I'ld normally do. --upas-erixiuoebvqmkjuozqzwuyhsos Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon May 12 05:13:17 EDT 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon May 12 05:13:15 EDT 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 9D23719A97; Mon, 12 May 2003 05:13:10 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from mercury.bath.ac.uk (mercury.bath.ac.uk [138.38.32.81]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id CC01519A7B for <9fans@cse.psu.edu>; Mon, 12 May 2003 05:12:04 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 19F97G-0007A1-00 for 9fans@cse.psu.edu; Mon, 12 May 2003 09:57:02 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3EBDBBDC.3090300@null.net> Organization: University of Bath Computing Services, UK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: <3EBBF24B.3020508@ameritech.net>, <1052587025.734.55.camel@pc118> Subject: Re: [9fans] same functions everywhere Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Mon, 12 May 2003 08:56:43 GMT John Murdie wrote: > (To counter my own argument, though, I remember reading something that - > I think - Doug McIlroy wrote about error handling code in telephone > exchanges; the code had been known to recover successfully from errors > that the designers had not anticipated. That said, I'd rather not trust > to such luck.) The point is, it wasn't luck, but rather a global strategy that would handle whatever had not been explcitly identified in advance as a possible problem. The problem with embedded error recovery in predicate-transform approach is that the Boolean expressions become unwieldy very quickly; by their nature exceptional conditions are a wart that don't fit cleanly into the main logic flow. If you cram them into the main flow anyway, then the complexity increases to the point that no programmer can completely grasp it. Of course, for "toy systems" almost anything will work if enough thought goes into it, but for large, intrinsically messy systems, methodology for bringing complexity under control is essential. --upas-erixiuoebvqmkjuozqzwuyhsos--