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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: "John W. Sarkela" Subject: Re: Exceptions as objects (was Re: What is wrong with OO ?) Date: 1997/01/29 Message-ID: <32EF8572.77E6@enfish.com>#1/1 X-Deja-AN: 213023729 references: <5acjtn$5uj@news3.digex.net> <32e9e445.163056932@library.airnews.net> content-type: text/plain; charset=us-ascii organization: Enfish Technologies mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (WinNT; I) Date: 1997-01-29T00:00:00+00:00 List-Id: Piercarlo Grandi wrote: [...] > But really the biggest problem of the mechanism is that it presents as > something complicated and special, to the point of requiring its own > control structure, chapter in the book, papers, and so on, what is an > entirely simple thing, as long as one presents it as: dynamic scope > +optional control transfer. I would advance the argument that the nature of the most appropriate exception mechanism will vary as one adopts procedural, functional or object oriented points of view. As an example of why I think objects modeling exceptions are right, I would use the point of view first expressed to me by Bertrand Meyer, programming by contract. Using the exception mechanism with which I am most familiar, Visual Smalltalk's. In human interaction, a contract is a document that describes a promise of service to a client. A contract has three important qualities. 1. It is observable by client and supplier. 2. It is verifiable by client and supplier. 3. It is enforcable by client or supplier. When either the client or supplier detects that the terms of the contract have been violated, the situation is sent into arbitration for resolution. In my programs exactly the same holds true. When assertions about the state of execution have been violated, I create an instance of an exception that models as carefully as possible all of the information about the observed violation of specification. Thus, from an object modeling perspective, the exception object serves as the court of arbitration for disputes between clients and servers. Handlers may be set associated with method activation records. Each handler serves as a local arbitrator for the signaled exception. If recovery is not possible, the dispute may be passed to the next higher authority. If none are found, default rules may be handled by the exception object itself. I have found this model of exceptions and their handling to be both intuitive and effective. The fact that non-local control transfers occur is not really a problem conceptually, because the control unwinds the chain of activations that led to the exceptional situation in the first place. This is a rational, structured, normal handling of exceptions in an object model. If I were using a functional language, then total functions would be a more appropriate point of view. However, for an object oriented language exceptions as objects provide a rich implementation mechanism for supporting the design notion of programming by contract. John Sarkela jsarkela@enfish.com