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

[piercarl@sabi.demon.co.uk (Piercarlo Grandi)]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

bobduff> In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
bobduff> Piercarlo Grandi <piercarl@sabi.demon.co.uk> 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.