When does void make code less re

[jim at ISM780B.UUCP]

>You've missed my whole point, Doug.  The low-level routines are not
>pre-empting the decision on how to handle errors, they are aiding in
>the implementation of the most common decision:  "on error, print a
>message and die".  By calling (say) emalloc rather than malloc, the
>higher levels are signifying their decision to adopt this strategy,
>and are asking the lower levels to handle the implementation.  There
>is no difference in power or flexibility, only in ease of use.

Fine; so why aren't there e* versions of every routine that might possibly
produce an error or call a routine that might produce an error?
And why not have versions that write their messages in different languages
and to different file descriptors?  (These are rhetorical questions.)
A special case like emalloc is just a wart, making clear the absence of a
decent global strategy.  I think catch/throw is the best, but even
the PWB fatal package or the USG matherr approach makes for far far better
software engineering than emalloc.  The existence of emalloc just encourages
you to write a subroutine that calls it, but I can't call your routine because
you have preempted the error policy decision.

>Note my earlier comment about the usefulness of a global s/malloc/emalloc/
>in Berkeley code.  By requiring the caller to do the work of checking
>for success, even when there is nothing meaningful to be done about
>failure, the bare malloc interface encourages sloppy programmers to
>ignore the whole issue.  It also makes conscientious programmers do
>repetitive and annoying extra work.

You have made a common error:  the existence of a problem is in no way
a justification for any specific solution (this applies well to
"initialize first member" too).  The key problem is that the current default
action when malloc fails is a core dump or other random behavior.
I would argue that the right solution is to make the default be an error
message and exit, but to allow that behavior to be modified, which emalloc
does not allow.

-- Jim Balter, INTERACTIVE Systems (ima!jim)