QuoteOriginally posted by: CuchulainnQuoteOne style of programming would have functions assume that all inputs are valid and all internal functions return valid values. The opposite extreme would have each function ensure that every possible error in inputs or internally received outputs of other functions is somehow caught and managed.This is the Design by Contract idea. An issue is how to make it all consistent. Who assumes what? Bertrand Meyer ==> customer is always wrong.C++ falls down IMO here. Standard exception hierarchies are frowned and current wisdom is to use noexcept?? C++11 compiler builders stand up
Thanks a bunch :)If the customer is always wrong, what about the supplier? If one cannot trust the inputs to a function, why should one trust the outputs of a function?If one can assume that certain communications or data within a system are always provably correct, then one can write much more efficient code that doesn't have to check every single bit every single time for errors. Yet as soon as one opens up such as system to outside calls (or down-the-road extensions or maintenance ), then we can't trust provable correctness. Maybe that is the overall point here -- that correctness is fragile and that rampant checking (and rechecking) of inputs and outputs is robust.Personally, I think exceptions seem like a good way to handle anomalous qualitative outcomes associated with quantitative computations (e.g., non-convergence, out-of-bounds results, singularities, non-trivial incorrectness of inputs, etc.). Exceptions let one codify these events for mitigation. Returning a NaN is like facing a wailing baby -- one knows something is wrong but can't tell the cause.