Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.programmer
Subject: Re: Complexity of reallocating storage (was users command crap)
Message-ID: <17660:Feb706:04:4191@kramden.acf.nyu.edu>
Date: 7 Feb 91 06:04:41 GMT
References: <29421:Feb419:13:5891@kramden.acf.nyu.edu> <8921@sail.LABS.TEK.COM> <1991Feb07.013637.6542@convex.com>
Organization: IR
Lines: 27

In article <1991Feb07.013637.6542@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
> Regarding problem 1, I like to see error messages in this form:
>     program: operations on object: reason

It's even better when you're given an error level: debug, info, warning,
critical, fatal.

> On problem #2, I think that if you have no stderr, (and even if you do
> for system programs) you should also syslog the problem.  It's not a
> perfect solution, but it's surely better than nothing.

Okay, you're right. In alt.sources is my first distributed program that
actually makes some use of syslog. I'm still worried that people will
think syslog is reliable or secure, and I'm very worried that someone
may come to depend on syslog or believe that it isn't worth using better
systems. But for the moment I guess it is the best alternative.

> I know people say not to check for errors that you don't know how to
> handle.  I think they're wrong. That's what asserts are all about.

Huh? An assertion is just one type of error handler, and a very clumsy
one at that. Dumping core is rarely the right way to handle an error in
a production program.

---Dan
Stupidity, n.: An overwhelming desire to rewrite one-line shell scripts
as 36-line Perl scripts so they run 6% faster. See Christiansen, Tommy.