Re: dispatching on keywords

[dyer@eagle.sharebase.com (Scot Dyer)]

From: birkholz@crl.dec.com
///    It is correct that un-anticipated exception values will 'cascade' in
///    this kind of a scheme.  This is handy in that it produces a
///    back-trace which it is simple to build a browser to view.
/// 
/// It is _not_ handy in that it produces something that could be
/// _mistaken_ for a backtrace.  Why throw away the stack in order to
/// generate something that looks like the stack but from which you can't
/// continue?

Well, if the stack weren't actually destroyed on exit from a function with an
error value (this is easy enough for a compiler to do)*, the stack can still
exist when and if method-dispatch can find no appropriate method to continue
with.

In my own personal code, I would re-call the function with parameters that
don't create an error, but I don't want to force my style on other people.
This was actually an unexpected issue, but if you read on, I think it can be
resolved with little loss of elegance (and only 1 function and 1 class)

///    This is a good argument.  Sometimes one wants errors handled
///    transparently, I'll admit to that, but having that be the _only_ way
///    can make life harder when you just want to define a simple function
///    like
/// 
/// 	   (define-method file-exists? (file-name)
/// 		   (not (error? (open-file file-name))))
/// 
/// This is a situation where the context of an error happens to be
/// unimportant.  I don't think it justifies throwing away potentially
/// relevant information (i.e. pop the stack) by default, for errors you
/// weren't expecting -- errors for which any relevant information may be
/// crucial.  It _should_ take a few more keystrokes to abandon the error
/// context in this situation.

Yes, and I would assert that this is a goodly number of the cases where one
wants to be able to detect an exceptional condition.  Insisting that non-local
control be used forces programmers to obfuscate such simple constructs in
their code.

Perhaps if a re-start mechanism were availible you would be more ammenable to
this scheme?  I think it would be easy enough to provide one.  Something like
(restart <restartable-error>).  Restartable conditions could inherit from
the abstract class <restartable-error> which provides a slot 'continuation'
that can be called.

	-- Scot

--
* Leaving the stack un-touched if an error occurs is actually _trivial_
  compared to trying to determine what functions have stable return types.