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: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: Exceptions as objects (was Re: What is wrong with OO ?) Date: 1997/01/28 Message-ID: #1/1 X-Deja-AN: 212814898 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <5acjtn$5uj@news3.digex.net> <32dd9fc8.262114963@news.sprynet.com> <32e9e445.163056932@library.airnews.net> content-type: text/plain; charset=US-ASCII organization: Home's where my rucksack's mime-version: 1.0 (generated by tm-edit 7.94) newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-28T00:00:00+00:00 List-Id: >>> "jeffries" == Ronald E Jeffries writes: jeffries> On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo jeffries> Grandi) wrote: piercarl> Let's start with the nature of exceptions. The first point is piercarl> that if a procedure implements a total function then it will piercarl> never have an exception. piercarl> Therefore exceptions arise only and only if a procedure piercarl> implements a partial function, and arise only and only when piercarl> the inputs to a procedure are outside its domain. jeffries> Yes ... and then you go on to make the function more robust, jeffries> which would be a good thing when it's practical. But as you jeffries> point out, the exceptions arise when the inputs are out of the jeffries> range contemplated by the function as written. jeffries> Exceptions, however, whether represented as objects or long jeffries> jumps, are about handling the unexpected. Not quite -- they are precisely about handling the *expected*, but *undefined*. By definition you cannot handle the unexpected, I would say. [ ... ] jeffries> In a project I'm presently working on, the input routines try jeffries> to handle all the errors. Then when the application definers jeffries> decided what kind of notifications they wanted on input jeffries> errors, we had to go in and edit the input routines and change jeffries> them all around to get the job done. Had they just thrown an jeffries> exception, we could have fielded the exception where we wanted jeffries> to, and filed our notifications and gone on. Ah, but that's precisely a good example that shows that exception handling (a terrible misnomer) is about dealing with the expected, but undefined. It is expected that the ``user'' will do strange things, but since it is as yet undefined what strange things will happen, one punts to an handler define by a dynamic-context, and this is the very reasons for having dynamically scoped identifiers. Put another way exception handling is when the required precondition of a procedure is weaker than that of the procedure one actually is in a position to write. The difference is then filled in by calling dynamic-context dependent ``handlers''.