From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_20,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!coopn1.csc.ti.com!knoll From: knoll@coopn1.csc.ti.com (Ed Knoll @(719)593-5182) Newsgroups: comp.lang.ada Subject: RE: pre-condition vs post-condition Message-ID: <9103161442.AA15853@tilde> Date: 16 Mar 91 14:42:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: >is raised. Should the given country's presence be listed as a pre-condition >for this function, or should its absense (it doesn't exist) and the raising >of COUNTRY_ERROR be listed as a post-condition? The answer is that neither post- or pre-condition is best, or rather both are based on the context of the situation. How is the module being used? What is the scope of the module? Is it a reusable component? Does it interface with other modules in a known or "friendly" environment, or is it interfacing/interacting with external subsystems of unknown quality? For a module which is part of the internal workings of a subsystem, a pre-condition would be more reasonable. It makes more sense for every module to insure that the data they pass on/generate is always correct. If modules of the same working subsystem have to verify all inputs, too much overhead/coupling is incurred. However, if a module is interacting with components external to a subsystem and these components are unknown/unrelated to the local subsystem, it makes more sense to do the error checking and to document the exceptions as part of the behavior of the subsystem. Well behaved subsystems under valid and invalid stimulus will be more portable/reusable then subsystems which react unpredictably in the presence of invalid stimulus. Ed Knoll Texas Instruments knoll@coopn1.csc.ti.com