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: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public 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: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Bryan Dollery Subject: Re: Exceptions as objects (was Re: What is wrong with OO ?) Date: 1997/01/25 Message-ID: <32EA5E85.631A@Bryan.ftech.co.uk>#1/1 X-Deja-AN: 212178434 references: <5acjtn$5uj@news3.digex.net> <32dd9fc8.262114963@news.sprynet.com> <32e9e445.163056932@library.airnews.net> content-type: text/plain; charset=us-ascii organization: ByteSmart systems Ltd. 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.01Gold (Win95; I) Date: 1997-01-25T00:00:00+00:00 List-Id: Ronald E Jeffries wrote: [...] > Exceptions, however, whether represented as objects or long jumps, are > about handling the unexpected. Nice misconception. Exceptions are deviations from the rule. There has also been some discussion in this thread about partial/total functions, and how total functions don't need exception handlers (all implementations of functions are partial because the state of the underlying software/hardware can not be known, and this environment constitutes part of the input to the function, thus making any 'total' function partial, as some of its inputs are implied). I beg to differ. "Exceptions" aren't just techniques to handle errors in input, output or computation. Exceptions are exactly that, exceptions. The reason 'exception handlers' aren't called 'error trappers' is because they don't just trap errors. If one has a routine to search a list from a given position for a paricular value one could implement this algorithm: (pseudo-code) search( this, for, from ) { if from < this.LowerBounds or from > this.UpperBounds return -1 i := from while ( i < this.UpperBound) if ( this[i] = for ) return i loop return -1 } This has all sorts of problems. Uglyness is just one of them. However, without exceptions and attempt to tidy it up would just make it longer, and uglier. With exception handling: search( this, for, from ) try i := from while ( this[i] != for ) loop return i except return -1 end Ok, this does enforce the precondition that FROM has to be within the bounds of the list. But this is just a side effect, and could be made explicit with a comment, or even a condition statement, or an assertion. The main point is that the general rule is to itterate the list, and to find the required item. That is what this routine does. If something unusual happens, such as the item not being in the list, then an exceptional situation has arrisen. Perfect. This is of course not a perfect example, better ones could be found. It could, and probably will, be argued that a search routine generally has as good a chance of failing as succeeding. That is irrelevant. The point is that exceptions to general processing should be handled by exception handlers. As to the question of an exception being an object. I have done some research on this. It was proposed by my supervisor Dr Carl Bamford that a new interface be added to the class structure, to augment the Public and Private interfaces that are generally accepted by the C++ fraternity. This is an exception interface, to which exception handling classes could be bolted. This was a method by which information and control from exceptions could be gained. -- Bryan Dollery. MD ByteSmart Systems Ltd.