From owner-freebsd-current Tue Dec 9 11:56:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA28525 for current-outgoing; Tue, 9 Dec 1997 11:56:16 -0800 (PST) (envelope-from owner-freebsd-current) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA28441 for ; Tue, 9 Dec 1997 11:55:59 -0800 (PST) (envelope-from henrich@crh.cl.msu.edu) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.7/8.8.7) id OAA00729; Tue, 9 Dec 1997 14:55:49 -0500 (EST) (envelope-from henrich) Message-ID: <19971209145549.60899@crh.cl.msu.edu> Date: Tue, 9 Dec 1997 14:55:49 -0500 From: Charles Henrich To: Eivind Eklund Cc: perhaps@yes.no, freebsd-current@freebsd.org Subject: Re: VM system info References: <66jnt0$ddh$1@msunews.cl.msu.edu> <199712091643.LAA04851@crh.cl.msu.edu> <19971209195826.64951@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19971209195826.64951@follo.net>; from Eivind Eklund on Tue, Dec 09, 1997 at 07:58:26PM +0100 X-Operating-System: FreeBSD 2.2.5-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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