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: Patrick Logan Subject: Re: Software landmines (loops) Date: 1998/09/04 Message-ID: #1/1 X-Deja-AN: 387679371 References: <6sjms6$7c4$1@hirame.wwa.com> <6skcve$t6j$1@hirame.wwa.com> <6skoqu$8gc$1@hirame.wwa.com> Organization: Teleport - Portland's Public Access (503) 220-1016 NNTP-Posting-Date: Thu, 03 Sep 1998 17:54:52 PDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-04T00:00:00+00:00 List-Id: In comp.object Robert Martin wrote: : Patrick Logan wrote in message ... : > : >But you (the method developer whose method is throwing an exception) : >don't care what happens next. You only care that your method has held : >up its end of the bargain. : Agreed. : I think we are lost. : My initial point was that exceptions violate se/se structures, but we accept : that because they are extraordinary means of control transfer. Exceptions, : due to their extraordinary character, provide a benefit that outweighs the : cost of losing the se/se structure. Well, one could be compulsive about SE/SE and place all the exceptions at the bottom of the method. I don't do that, but I write small methods anyway, and I am becoming more aware of the importance of that over anything else under discussion in this thread. I will try to communicate better what I attempted earlier. It has little if anything to do with SE/SE. Previously you wrote: : >: [Upon return from a method invocation] there is a postcondition : >: that you can depend upon. But once you throw an exception, there : >: is very little you can say about what happens next. My point is that when you invoke a method, you are relying on that method's contract in order to *proceed* in fulfilling your own contract. But when you are throwing an exception, you *are* fulfilling your own contract. When you say "there is very little you can say about what happens next" I agree. Whatever you can say has been said. You have fulfilled your contract. End of story. Nothing else matters to you. My argument (if it can be called that) is really with Patrick's bringing this issue up at all. It is apples and oranges to me, and I'm frustrated because I don't know how to compare apples and oranges. (Sorry Patrick. I know you have a point, I just have not been able to grasp it yet.) I hope this helps, at least to point out the general vicinity in which I am lost! -- Patrick Logan (H) mailto:plogan@teleport.com (W) mailto:patrickl@gemstone.com http://www.gemstone.com