> ** Original Sender: Stephen Pope <stp at create.ucsb.edu>
>
> This is an interesting point to debate. I placed them under Error simply
> because the default behavior for the TFEI Notification class is to be a no-op
> *unless* it's handled, and I wanted these two to pop you into a notifier as
> you'd expect. Perhaps we need a third abstraction for non-errors that
> nevertheless interrupt the running process.
> 
> The second point is more important -- if these are not caught by a handler
> for the generic Error, it makes it quite hard to deliver end-user
> applications.

Ah, then perhaps the problem is simply that "Error" is misnamed.

I suggest the following hierarchy:

Exception (the root class, takes no action if no handler is found, proceedable by default)
	DefaultHandlerException (takes some default action if no handler is found)
		HandlerRequiredException (raises NoHandlerException if no handler)
			ErrorException (root of all errors, not proceedable by default)
			WarningException 
		NoHandlerException	(raised when no handler is found for a 
					HandlerRequiredException, opens
					default "UnhandledException" notifier
					if no handler found for NoHandler exception)
		ControlException 
			HaltException
			UserInterruptException 

--Alan