henry@utzoo.UUCP (Henry Spencer) (03/08/85)
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