Re: [9fans] Sam question

[Lucio De Re <lucio@proxima.alt.za>]

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