New year error handling

[Mary <Fontana%ti-csl.csnet@csnet-relay.arpa>]

I haven't seen anything from this committee since last year in October.
Have we resolved any of the following?

Definition of a condition and an error:
 - A CONDITION refers to "something that happens" during the
execution of a program.
 - An ERROR is a particular type of condition which is
associated with an event that has been detected by a program
as not part of its contract. When an error condition is
signalled, the program may not proceed without the condition
having been handled somehow. This implication is not
necessarily true of all conditions-- only of error conditions.
 - A CONDITION OBJECT represents a condition.  Holds
information about the particular condition, such as the message
describing the error, ways to proceed, data used by the
condition handler, ...

Creating a condition
  Like, MAKE-CONDITION or DEFSIGNAL

Signalling a condition.
  SIGNAL, ERROR, CERROR, .... (allow an argument for a condition name).

Establishing a handler.
   IGNORE-ERRORS, CATCH-ERROR, CONDITION-BIND, CONDITION-CASE,
CONDITION-CALL.  

What about resume handlers?  
Establish resume handlers with ERROR-RESTART, ERROR-RESTART-LOOP, 
CATCH-ERROR-RESTART, or CATCH-ERROR-RESTART-EXPLICIT-IF.

Proceeding & Proceed Types?
  Defined when create the condition object.  Also, CERROR and SIGNAL
provide ways to specify proceed types.  Rusume Handlers define proceed
types. (I didn't follow what Steve was proposing here last year).
  
What is the signalling mechanism?
  I'm assuming that functions, such as ERROR and SIGNAL, will "signal
a given condition" which means the system  first searches a list of
condition handlers for a previously established handler associated
with this condition.  If one is found invoke it,  otherwise (possibly)
invoke the Debugger. And finally look down a list of resume handlers.

-------