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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: Loryn Jenkins Subject: Re: Software landmines (loops) Date: 1998/09/05 Message-ID: <35F074C9.E10C3265@s054.aone.net.au>#1/1 X-Deja-AN: 388002794 Content-Transfer-Encoding: 7bit References: <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <6simjo$jnh$1@hirame.wwa.com> <6sjk3p$4tc$1@hirame.wwa.com> <6skgn4$3gq$1@hirame.wwa.com> <6sm6md$3fh$1@hirame.wwa.com> <35f1375e.6237208@news.erols.com> X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii X-Trace: news.mel.aone.net.au 904951024 19516 203.102.238.26 (4 Sep 1998 23:17:04 GMT) Organization: TekRite Pty Ltd Mime-Version: 1.0 Reply-To: loryn@acm.org NNTP-Posting-Date: 4 Sep 1998 23:17:04 GMT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-04T23:17:04+00:00 List-Id: > Testing for pre-conditions before processing is not equal to what the > try/catch idiom is about. Very true. > I advocate that in general we should test to see that pre-conditions > are met, and if they aren't, bail. Why even try to process if > pre-conditions have not been met? > > if (!pre-condition) > bail > else > do_processing() > endif This is an interesting approach to DBC: specify your preconditions and write your function to ensure the preconditions are met, else bail. However, I think Meyer's approach to DBC is more powerful than this. Basically, Meyer's approach is to make the calling routine check the preconditions, not the called routine. Imagine the following routine: put (v: SOME_ENTITY) is require not has (v) -- where `has' tests by OID. do ... ensure ... end I would argue that the calling routine is in the best position to check this precondition. For example, the calling routine may be creating an object, then inserting it into this object. It doesn't have to call `has' to make sure the object isn't yet inserted. Whereas, another client may have to check it. Checking for your own preconditions is simply defensive programming. The problem is that a calling class has no way of knowing (beforehand) whether the routine is going to work or not. Unless it too checks the preconditions, in which case your software is starting to be weighed down by multiple, repeated checks for consistency. And this is what preconditions and DBC is all about doing: eliminating uncertainty; eliminating the redundant code bloat of redundant error checking. On the other hand, if you're not going to expect your client routine to check the precondition, then you *must* handle everything yourself. (ie you shouldn't just *bail.) Why? Because that implies that the client routine is going to have to check *after the fact* whether the routine succeeded or failed. Then it's going to have to do something about it. You see, it would have been better to get the client routine to do its own checking before hand, then *expect* the routine to work. Now, when you observe this approach to DBC, then you gain a powerful insight into a disciplined use of exception handling. (Hint: It's used much less commonly than in the standard idiom apparent in C++ and Java world.) Loryn Jenkins