When does void make code less readable?

[Doug Gwyn <gwyn>]

Re: emalloc() etc.

I also often package malloc() in routines like NodeAlloc() etc. that
alloc the proper thing (e.g. a (struct node)) and perform the appropriate
action when the malloc() fails.  However, what the right action in this
case really is, is dependent on the application.  In production code, it
is seldom appropriate to just print an error message and terminate the
process.  I built an interactive drawing system once that had to keep
running in case of ANY foreseeable emergency, in order not to lose the
user's hours of work when there was a system failure.  In case of running
out of memory, it set a flag which would cause display of an "out of
memory" message at the appropriate time, and returned failure status from
the allocator to its invoker so something sensible could be done to
maintain the integrity of the linked data structures.  Note that there
was no "stderr" to print messages to (I had to arrange for messages to
appear in the menu area of the refresh display list), and the message had
to be deferred until the whole data structure had been processed, to
avoid a cascade of error messages when one would do.

I am not saying that such thorough error handling is ALWAYS required,
but I would encourage program designers to think carefully about the
handling of exceptional conditions wherever they may occur.  I fear
that providing an emalloc() in the standard library would mainly make
it easier for programmers to excuse their not thinking about what to do
in the error case.  It wouldn't be any worse than not checking for
malloc() failure, though.  What we really need to do is to figure out
some way to stamp out sloppy programming.  Any ideas?