... ask J.B. Goodenough, also note his mention of preconditions ("domain failures") and postconditions ("range failures").

The paper is not accessible for free (ACM account needed), but I've found a nice piece of summary of exception history (application/pdf, 141 KB) : In the Communications of the ACM in December 1975, John B. Goodenough discussed issues in exception handling, classifying the types of exception usages as (i) dealing with domain or range failure of an operation (ii) indicating the significance of a result, or (iii) permitting monitoring of an operation. When range failure is indicated, the operation may need to be aborted, retried or terminated yielding partial results. A domain failure requires modification of the input or an abort of the operation. Exception type (ii) is not a range failure, but requires that additional information be passed back to the user about the operation. Exception type (iii) is usually resumed after the user examines the information about the operation passed back by the exception. Not all of these are error conditions; Goodenough described them “as a means of conveniently interleaving actions belonging to different levels of abstraction” [6]. After reviewing some existing exception mechanisms of the time, Goodenough discussed requirements for good exception handling, which should ”help prevent and detect programmer errors” according to Gannon and Horning [4]. He argued the effectiveness of lexical (or static) association of handlers with operations that may throw exceptions. These included both language-defined and user-defined (subroutines) operations, with explicit declaration of those exceptions that may be thrown as the result of a call. He advocated compile-time checking of the completeness of exception handling. His model of exception handling included the possibility of resuming execution as well as termination, and allowed the use of default exception handlers. Related: I'm reading currently about Components, I was fascinated by the notion of security facade, and expert components that handle a diagnosis and recovery interface of the core component. Could this be a architecture principle developers should follow? It seems not so popular in these days, but JEE handles these issues somehow...