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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/09/01 Message-ID: <6sh4kf$adk$1@hirame.wwa.com>#1/1 X-Deja-AN: 386811871 References: <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@news.erols.com> <6sdiav$e0g$1@hirame.wwa.com> <6sfcft$70p$1@hirame.wwa.com> <6sfcu4$bks@saluki-news.it.siu.edu> <35ed3d4a.2378710@news.erols.com> <6sfqul$ggg$1@hirame.wwa.com> <35EBF28B.FD4F38EC@oma.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: WorldWide Access - Midwestern Internet Services - www.wwa.com Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-01T00:00:00+00:00 List-Id: Tim Ottinger wrote in message <35EBF28B.FD4F38EC@oma.com>... >But the question I have is what happens when we have exceptions. Those >are >most certainly an early exit and may occur at unpredicted times. How >do >the rules for single entry/exit apply in an exception-supporting >language? For exceptions, they don't apply. And because of that, language designers have bene forced to invent a suite of extraordinary language features to help deal with it. In C++, we use destructors to clean up resources. In Java we use 'finally' clauses. These solutions work, but suffer from the fact that the state of the algorithm may have been by the time they are entered; and such state may have to be recaptured by inspecting data elements (something very difficult to do inside a destructor!). In the end, one of the better schemes for dealing with exceptions is to re-enstate the single-entry/single-exit (se/se) mechanism by using fine grained try/catch blocks: try { // block 1 do something that might throw. try { // block 2, new algorithm state do something else that might throw. cleanup block 2. } catch(...) { cleanup block 2; throw; } cleanup block 1 } catch(...) { cleanup block 1. throw; } The 'finally' approach in Java is superior to this because it doesn't require the duplicated cleanup code. And when used in a fine-grained way can almost completely recapture the tracking of algorithm state that se/se structures do. Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan