Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Dec 1997 14:55:49 -0500
From:      Charles Henrich <henrich@crh.cl.msu.edu>
To:        Eivind Eklund <eivind@yes.no>
Cc:        perhaps@yes.no, freebsd-current@freebsd.org
Subject:   Re: VM system info
Message-ID:  <19971209145549.60899@crh.cl.msu.edu>
In-Reply-To: <19971209195826.64951@follo.net>; from Eivind Eklund on Tue, Dec 09, 1997 at 07:58:26PM %2B0100
References:  <66jnt0$ddh$1@msunews.cl.msu.edu> <199712091643.LAA04851@crh.cl.msu.edu> <19971209195826.64951@follo.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On the subject of Re: VM system info, Eivind Eklund stated:

> If you read carefully, you'd have found that there were quite a few other
> rules about commenting.  Have you ever tried reading code where variables
> are clearly documented?  It is _way_ easier to read than code that is
> directly documented.

I did read what you said, I only commented on those I disagreed with.
Variable commenting is important.

> There are four ways to cope: (1) Ignore error; return OK, even though the
> function failed to do it's job.  (2) Return error code (3) Throw an
> exception of some sort, e.g. longjmp().  (4) panic(), a la assert().

That depends greatly on the situation.  There is also a (5) that says take all
given known information and continue onward, while logging the error.  In some
cases its obviously not possible where a routine is designed to have no return
value.  This reminds me entirely of AFS, one of the worst pieces of kernel
code I've ever stumbled upon, that spends half its time in asserts() where
completely unnecessary.  Instead of taking a moment to figure out whats really
going on when a condition failed, the programmers took the easy way out, and
panic'd the machine.  Hardly acceptable in the case of a production
environment where users very well may lose months of ongoing work.

> present, and should be handled the same way - I disagree.  A complicated and
> sloppy system has a much higher risk of being buggy than a small and rigidly
> defined system which trap all errors as soon as possible.

Im not arguing the trap all errors as soon as possible piece, im arguing in
what you do when you detect one.  To shutdown the machine is the worst
solution.  Lets think for a moment about the case if your the computer system
on a F-15 fighter jet, the last thing the pilot wants to see is "Panic, system
halted" as he spirals to his death instead of the software attempting to cope
as best as possible.

-Crh

       Charles Henrich     Michigan State University     henrich@msu.edu

                         http://pilot.msu.edu/~henrich



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971209145549.60899>