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: jeffries@ic.net (Ronald E Jeffries) Subject: Re: Exceptions as objects (was Re: What is wrong with OO ?) Date: 1997/01/25 Message-ID: <32e9e445.163056932@library.airnews.net>#1/1 X-Deja-AN: 212111826 references: <5acjtn$5uj@news3.digex.net> <32dd9fc8.262114963@news.sprynet.com> content-type: text/plain; charset=us-ascii organization: INTERNET AMERICA mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-25T00:00:00+00:00 List-Id: On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote: >Let's start with the nature of exceptions. The first point is that if a >procedure implements a total function then it will never have an >exception. > >Therefore exceptions arise only and only if a procedure implements a >partial function, and arise only and only when the inputs to a procedure >are outside its domain. Yes ... and then you go on to make the function more robust, which would be a good thing when it's practical. But as you point out, the exceptions arise when the inputs are out of the range contemplated by the function as written. Exceptions, however, whether represented as objects or long jumps, are about handling the unexpected. My application system must keep on going, whether or not the input routines are prepared to deal with B's in the middle of the numbers, and dates like 2/31/1997. Complexity, lack of access to the code, limited resources mean that the input routines won't ever be made complete. And they can't know what their users want done with those B's and weird dates anyway. At the same time, when using the input routines, it is impractical (costly and error-prone) to have every call to the routines check for errors. It is much more practical and convenient to choose a standard place where, if an input error occurs, a default action can be taken. In a project I'm presently working on, the input routines try to handle all the errors. Then when the application definers decided what kind of notifications they wanted on input errors, we had to go in and edit the input routines and change them all around to get the job done. Had they just thrown an exception, we could have fielded the exception where we wanted to, and filed our notifications and gone on. While complete program correctness is an interesting science, it is not something that we often attain in practice. Exceptions are a simple and practical way to deal with the faults we humans often leave in our programs and our data. Regards, Ron Jeffries Smalltalker How do I know what I think until I see what I type?