> The user interface to control exception behavior is:
> -----------------------------------------------------
>

We may also want to have to add method like IsIgnored() and GetHandler()
so that you can set a temporary control behavior and then return to the
previous behavior.

	Done.  Not as simple for IsIgnored because there are 3 states including
	"never specified" but see wha\t we have defined now.


It has been mentioned that the definitions on the subclasses supersede
(spelling ?) the behavior defined for the top class.  We may want to provide a
way to
over-ride this behavior so that one is easily able to ignore all the exceptions
types no matter what was set before.

	No.  Because then there ought also to be a way to specify that a
	particular routine be handled (or whatever) in spite of what you
	said in general...  Since we can never end that path, let's just
	stop at the beginning.
	
>     The signature of the handler may be either:
> 	bool myhandler ( ZMexcept x, string message );

The message seems redundant since the exception x already contain a message.

	Good point.  In fact, this cures another worry I had, about the
	dual-signatures for handler.

> ... ZMexception object constructor, which
>    has as ITS first argument a const char*.