Re: Exceptions as objects (was Re: What is wrong with OO ?)

[lgmayka@sprynet.com (Lawrence G. Mayka)]

piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

>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...

Ironically, though, your first posting in this thread was a response
to =my= posting, pointing out to Mr. Stroustrup that his design for
exception handling was implemented years earlier in Common Lisp.  As
you may know, Common Lisp has long had both nonlocal control transfers
(THROW and CATCH--perhaps Bjarne even borrowed his keywords from
Lisp!) and dynamically scoped variables (as an option, along with the
default behavior of lexical scoping).  Indeed, some implementations of
ANSI Common Lisp exception handling do indeed employ these earlier
constructs.  Just as you suggest, dynamically scoped functions are
easily simulated via dynamically scoped variables whose values are
function objects, or via syntax extension (the Common Lisp
macroization system).

But what your scheme lacks is a classification or "matching"
mechanism.  Common Lisp was well-prepared to provide this because,
even before the standardization of CLOS, it offered the
single-inheritance capability of DEFSTRUCT and the type-testing
operator TYPEP; and so the Pittman Condition System was implementable
entirely on top of 1985-vintage Common Lisp constructs, yet easily
extendible to CLOS later.

One other very useful element both your scheme and that of C++ lacks
is that of closures as handlers.  Very often, an exception handler is
more comfortably and easily written as a lexically scoped function
that manipulates the variables of an outer function.  Again, Common
Lisp already had full-power lexical closures by 1985, whereas C++
still doesn't.

You may ask, if a language such as Common Lisp already has all the
necessary base capabilities, why provide the "syntactic sugar" of
exception handling constructs?  To clarify, standardize, and perhaps
optimize conventional usages.  Since Common Lisp supports syntax
extension (a powerful macroization system), programmers would probably
be writing such syntactic encapsulations anyway; we may as well
standardize them to enhance portability of programs, skills,
knowledge, etc.


Lawrence G. Mayka
lgmayka@sprynet.com