Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!NewsWatcher!user
From: miller@cs.rochester.edu (Brad Miller)
Subject: Re: Help with conditions
Message-ID: <miller-0411941554290001@199.89.214.2>
Sender: news@cs.rochester.edu (Usenet news)
Nntp-Posting-Host: 199.89.214.2
Organization: University of Rochester Computer Science Dept.
References: <CypAMv.n3n@undergrad.math.uwaterloo.ca>
Distribution: na
Date: Fri, 04 Nov 1994 15:54:29 -0500
Lines: 64

In article <CypAMv.n3n@undergrad.math.uwaterloo.ca>,
wewallac@watcgl.uwaterloo.ca (Bill Wallace) wrote:

> I have been looking at CLtL2, at the conditions section, and have used
> conditions in other languages, but I don't quite understand the usage
> of conditions.  What I would like is someone to send me a short example
> of the use of conditions.  Something like:
> 
I can certainly understand your frustra after reading the chapter 3 times, I
still make brainos. Conditions is one part of CL that is really crying
out for a good tutorial. 

Anyway, I have some ftpable code, but I couldn't call it a good example;
better examples I don't yet have available for public consumption. 
Perhaps we can engage in a conversation offline (that is, email) and
I'll try to give you some additional intuitions.

Basically you want to think of conditions as a function that will be
run in the dynamic context of the signaller. That is, you signal a condition,
the handler takes over, deals with it, and you KEEP RUNNING. For instance,
you might drop into the debugger to ask the user what to do, but since you
can examine the state and intelligently decide what to do for the particular
condition handled, you don't necessarily need to dialogue with the user
at all. (for those of you listening in from the namespace discussion, note that
in english, we can handle the fact that words can be both nouns and verbs. 
Why not have that feature in our programming languages?)

Handlers, upon examining the state of the error, can decline to handle the
error (by returning nil). If they do that, the next handler that might
handle the error is called.

Of course you CAN set it up to do something like catch/throw, and some of
the macros do just that. That is, the handler can certainly execute a throw
to any dynamically apparent catch, e.g. where the handler was bound. Another
thing you can do is look to see if there are available handlers. That would
be one way to decide if you want to just handle the event locally before
signalling (if you know no handler will answer). I usually do this by setting
up a local handler, signal the error, and if the local handler can find another
handler, it returns nil (so the next handler will be called), otherwise,
it deals with the "problem" best as it can.

Since all this is based on CLOS, it's an extremely powerful mechanism for 
building hierarchical handlers for events. The events need NOT be unexpected,
or errors:

in one program, I use this mechanism as a simple substitute for continuations;
in another case, I use it to generify subroutines that will be used by
different processes, each of which can bind appropriate handlers for (expected)
errors, depending on if they can communicate with the user (front end) or
will be anonymous back end processes, possibly running on different machines.
For such processes, it's also easy to build generic error handlers to handle
ANY signaled error and package them up as a message to the user i/o process.

All in all, it's an EXTREMELY powerful (and dangerous**) system. Try some of 
the examples in the book, then plug away at slightly more complex things, like
handling errors in background processes that don't have a binding for
*terminal-io*.

[** Dangerous in the sense that you can muck up existing error handlers, and
change the way the code works. That's good, if you know what you're doing. I
like dangerous languages; I'm not trying to discredit the condition system
here. Languages that know better than you what "should" and "shouldn't" be
done are generally hard to use, and take longer to acheive particular kinds
of goals with. But then, I'm an anarchist.]
