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,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,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 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: 212830172 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <5acjtn$5uj@news3.digex.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: >>> "bobduff" == Robert A Duff writes: bobduff> In article , bobduff> Piercarlo Grandi wrote: piercarl> The obvious and correct solution is to make the name of the piercarl> procedure dynamically scoped; then it can be redefined piercarl> whenever this is needed. bobduff> How about this: The exception-handler is a procedure that is bobduff> passed to the procedure that detects the error. So, in your bobduff> sqrt example, the sqrt function would take a Float parameter, bobduff> and a function to call in case the Float is negative. This is bobduff> essentially how Smalltalk does things. If you allow defaults bobduff> on parameters, then you can make the default handler be "print bobduff> out a message and kill the program" or "enter the debugger" or bobduff> whatever. So callers only have to worry about it if they want bobduff> to do something special on sqrt(negative). bobduff> Is this not pretty much equivalent to your dynamic-scoping bobduff> scheme? It is indeed entirely equivalent for that is a (xxx-reduction it the technical term, I don't remember offhand which greek letter stands for xxx), a way to transform global (dynamically scoped) variables into procedure parameters. If one does not like global variables, dynamically scoped or not, one can transform them into parameters to all procedures that access them. But then for all their awfulness global variables, and even dynamically scoped global variables, are useful, in the sense they are merely convenient, for the xxx-reduction involves a bit more verbiage. With non-too-clever implementations adding defaulted extra arguments can also result in distinctly inferior code, because it involves passing an extra argument for each potential ``exception'' one wants to handle. Consider for example floating division: it would require at least three extra ``implicit'' arguments/parameters (overflow, underflow, illegal divisor). bobduff> And it has the advantage that the relevant information is in bobduff> the specification of the procedure that wants to "raise" the bobduff> exception. This is not a big advantage; one can achieve the same effect by requiring, as some languages do, a procedure/module to ``import'' explicitly any global (or fluid) variables it will make use of.