Regarding what he calls "soft errors" (a better name would be environmental errors, I think), it's unfortunate that option 2 (error handlers) is so often neglec

Regarding what he calls "soft errors" (a better name would be environmental errors, I think), it's unfortunate that option 2 (error handlers) is so often neglected by programming language designers (for example Code Complete doesn't mention option 2 at all). In my view, just like option 4 (exceptions) is more general than option 3 (return values), also option 2 is more general than option 4. The biggest advantage of 2 compared to 4 is that recovery is much easier. However, more generality also unfortunately means more complexity (both for programmer and runtime). That's why many people here prefer 3 to 4 or 2, and neither one of them is really better than the other. Common Lisp is a good example of language that has good support for all three. It can return multiple values which facilitates option 3, it has usual exceptions as option 4, and most importantly, it also has signals and restarts that serve as option 2. I would classify what he calls hard errors into two categories. One is inconsistent input and the other internal (logic) error. This depends on level of view, if you are looking only at one module or a bigger whole (inconsistent input into one module from the other can be considered internal error in the whole). Now, I don't think inconsistent input should be dealt with asserts. If it's worth checking the inconsistent input at the module boundary, do it and return an error (in any of the three ways mentioned above). The caller should decide whether or not this is a logic error (it may also be bad input from the user), and how to handle the failure. While I agree with the statement that on logic errors one should generally fail hard, sometimes it's not desirable, for instance in server you may want to just restart the wrong thread instead of shutting down the whole server. Finally, I think asserts are very much underrated in the current development practices, compared to tests. I wish the effort spent on testing frameworks would be spent on frameworks that would let you add lots of asserts into the code and turn them on/off as needed (for example based on required tradeoff between reliability and performance).