From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Sam question Message-ID: <20010819142342.S6233@cackle.proxima.alt.za> References: <20010819085726.Q6233@cackle.proxima.alt.za> <034701c1289d$4b8be380$3cf7c6d4@SOMA> <20010819131308.R6233@cackle.proxima.alt.za> <036801c128a6$db4aa930$3cf7c6d4@SOMA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <036801c128a6$db4aa930$3cf7c6d4@SOMA>; from Boyd Roberts on Sun, Aug 19, 2001 at 02:02:44PM +0200 Date: Sun, 19 Aug 2001 14:23:42 +0200 Topicbox-Message-UUID: e2b27bcc-eac9-11e9-9e20-41e7f4b1d025 On Sun, Aug 19, 2001 at 02:02:44PM +0200, Boyd Roberts wrote: > > the trouble is that the mess you are trying to get out of may > be extremely inelegant to test for at the end of the outer loop. > > it's usually error cases that screw things up and destroy perfectly > good loops. > Agreed. And it isn't always feasible to test in advance, although even when it is, one may inherit a previous pile of spaghetti. With errors (I like to think of them as contingencies), one knows something may go wrong, but not what, only the effects can be identified (an NFS service is unmounted, or a file is corrupt, whatever). The "try/catch" approach makes sense, but a clean (nevermind elegant) implementations would have to pass a lot of criticism. Yet the alternative is the dreaded "goto" - better the devil you know syndrome? Hm, the other contributing factor is the lifetime of code. One never expects prototyping code to be still running 20 years later, yet I doubt there's much that is proper production-quality code out there. If one profiled code for a while, the uncertainty in the middle of a loop would eventually turn into predictable events and the "goto"s could be replaced with precondition testing. But who profiles prototypes? ++L