Sloppy error checking in MS code

[Glenn Steen]

On 16/12/06, Mike Jakubik <mikej at rogers.com> wrote:
> Julian Field wrote:
> > Ken,
> > Thanks for backing me up. Yes, I don't check the return value of every
> > single call I make, but show me a programmer who does? (No doubt someone
> > will at this point). The most common point that is made is "what if the
> > system runs out of space" at this point, and all sorts of things will be
> > failing at this time, there isn't any need to create more errors at this
> > point, they just create noise. Yes, I quite happily admit I don't check
> > the result from everything I do. But if you want a practical piece of
> > software that runs at a reasonable speed.
> >
>
> How much of a performance impact does a check for the return value of a
> system call produce? I believe what distinguishes good software from bad
> is how the software handles errors. What you are saying seems to
> contradict, as Matt Kettler stated that identical functions have error
> checking in the sendmail code, but not in postfix. No, i don't check to
> see if there is a floor when i wake up, but the chances of an I/O
> function failing because someone tampered with the directory/changed
> permissions/disk run out of space/some other OS/HW problem are MUCH
> greater than my floor disappearing. While i have not experienced any
> problems myself (AFAIK), it would at least shut up the postfix users/MS
> haters.
>
There is such a thing as being _too_ conscientious too Mike. I fondly
remember retiring a communication handling system (written in C) that
checked every return code meticulously _and then did the wrong
things_, thus becoming the problem instead of solving it... I replaced
that with a rather well thought out brood of perl scripts... Went from
at least one severe "error" (where production (ID cards) ground to a
halt) to ... no errors for the next 4 years, not counting the very few
times when the customers mainframe "on the other end" had a hiccup
(which was infrequent).

I'm pretty certain we don't have any real problem here, but I do agree
we should take the time to look. Personally, I can't help with that
just now, but will be aiming at doing something around mid-January.
Nothing stopping you (or Matt) from continuing now though:-):-).

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se