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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,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: 212869983 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <5acjtn$5uj@news3.digex.net> <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: >>> "bobduff" == Robert A Duff writes: [ ... ] bobduff> What you say above is the whole point of exceptions -- one bobduff> piece of code detects an error, and a different piece of code bobduff> decides what to do about it. And Mr. Grandi's scheme is just bobduff> as good as the C++/Ada scheme, in this regard. (I'm not sure bobduff> why Mr. Grandi thinks his scheme is so vastly superior, bobduff> though.) Actually, it's not *my* scheme, it has been known for thirty years or so; and then it is not quite "vastly superior", it is just the right thing to do; my point is that: piercarl> So, basically *everything* is wrong (and clumsily so) with piercarl> the ``C++'' exception-as-object system: piercarl> * the name of the exception class should be that of a piercarl> dynamically scoped procedure. piercarl> * an exception object is really just a clumsy and silly way of piercarl> specifying an argument list to that dynamically scoped piercarl> procedure. piercarl> * non local control transfers are then mandatory. These things are wrong because they involve a clumsy and limited mechanism. Dynamically scoped identifiers are usuful for a number of cases where actions must depend on the program context; dynamically scoped variables, not just procedures, are very useful too. Non local control transfers are also very useful in their own right. Now, ``exception handling'' presents as an ad hoc, and often pretty ungainly mechanism, a particular, and restrictive, combination of the fundamental concepts of dynamic coping and non-local control transfers. It is much better to provide the two things separatley, for this allows for example ``exception handling'' _without_ forcing control transfers, and control transfers without necessarily involving dynamically scoped identifiers. And then runtime parametrization via dynamically scoped variables... 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.