All the error handlers are loaded, whether they're used or not.  This is
because of the initializations in Exception.C.

If the exception handler initialization was put in the appropriate
exception file (e.g. Exch_abort.C, Exch_warn.C), and the RAISE and STOP
macros contained a reference to the handler function, instead of using
a symbol, the problem would go away.  How about using the address of the
exception handler instead of a symbol to identify exception's?

<< We still need a symbol to identify an Exception.
<< There could be more than one exception handler defined
<< for a given Exception.  (The most recently established handler
<< would be the one invoked, if the exception is raised).
<< The exception handlers in Exception.h  are defaults
<< which would be invoked if the programmer did not define their own.
<< -- MJF.

Another advantage of not using symbols, is that if a symbol is mis-spelled,
(i.e. error instead of Error) the problem will be cought at compile time.
<< Won't the compiler catch it anyway??  RAISE(error) would expand to
<< Exception_g = new error;  If error is not a type it would complain. --MJF

Currently, when an exception handler name is mis-spelled, or otherwise
unknown, the exception software IGNORES error.  This is bad news.
There should be a new error handler called Unknown, which is invoked
when no other handler can be found.
<< What will Unknown do?  Should it report a the error message and continue?
<< We could think about how it is done in Common Lisp.  Here,
<< if the exception type is error, the Error Handler (ie, Debugger) is called.
<< But if the exception is not of type error or fatal, it just returns
<< to the code that raised the exception.  -- MJF


void eh_signal(int signum) {
  This has its code commented out.  What's it supposed to do???

<< eh_signal is not implemented yet.
<< eh_signal was the handler function passed to the UNIX
<< function signal.  It would establish a COOL exception handler
<< -- somehow link the UNIX signal facility to the COOL
<< exception handling scheme.     -- MJF

void system_signal_handler (Exception* excp)
  This has the code:
  excp->report(cerr);		// report signal message
  // now what ...

  This comment makes me nervous.  What's supposed to happen here?

<< the system signal handler is not implemented fully.
<< it needs to somehow interface with or replace the current
<< way UNIX signals are raised.  These are asynchronous events usually.    
<< mjf
