error handling and emalloc

[Henry Spencer]

Doug's point (that print-and-die is not always valid error handling)
is correct.  However, elaborate error response generally is appropriate
in about three situations:

	1. program is interactive (don't want to just dump the user)
	2. program is very long-running (don't want to lose all that work)
	3. program is altering precious data (partial run is unacceptable)

Note that 1 often implies 2, as in Doug's example of hours of work in
an interactive program.  (Although system crashes do happen, and it's
nice if an interactive program can recover from them too... mechanisms
to do this may alleviate the drop-dead problem somewhat.)

I would observe, though, that many Unix programs fall into none of these
categories, and the extra effort on highly-intelligent response to a
"can't happen" error may not be worth it.  What *is* unacceptable, as
noted in the Darwin&Collyer paper at Dallas, is ignoring the whole
possibility of "can't happen" errors.  emalloc() is a cheap and simple
way of avoiding this pitfall.  I do not suggest that it's a complete
approach to malloc error-handling in general.  As for the possibility
that it may encourage sloppiness... the people who will use emalloc
as a substitute for thinking about error recovery are the ones who
will use malloc without checking the return value.  The net effect is
quite definitely an improvement.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry