ZOOM Exception Mechanism Design
		-------------------------------

The Zoom exception mechanism is intended to be the tools used by ZOOM modules
to handle exceptions in a useful way and provide the user with interfaces to
control how to react to problems.  It is not (at this time) intended to be a
mechanism for the user to hook into to define his own exceptions, although that
may come later.  Frankly, successful implementation and use by ZOOM modules
will
be necessary to sell this structure to our users as potentially useful, anyway.

We need the mechanism "now" because we are trying to deliver at least two
packages which will have to be re-instrumented when the mechanism is finally
adopted.

This is not a "signal handler" mechanism, which could be used to establish
behavior for segment violations, arthmetic exceptions, and so forth.  It
would be nice to have this but C++ does not provide generic support for
those activities.  A **later** possibility will be to provide this support for
POSIX-compliant operating systems, and coordinate it with the exception
mechanism.


We need to be able to cope with the following realities:
- --------------------------------------------------------

1 - Users will not, in every case, imbed calls into a try block.

2 - Frameworks will incorporate code from multiple users and in some
    circumstances cannot afford to abort the entire job if some rare path
    in one user's code blows up.  To the extent we can help with this, we must.

3 - Framework creators CAN be expected to imbed portions in try blocks, or
    set up behaviors for various exceptions, assuming we give them the
    necessary tools.

    In the remainder of this document, the "user" who sets things up is assmued
    to be such a framework manager.

4 - There is need for coordinated logging and related behavior.


To be able to satisfy this, the goal is to allow:
- -------------------------------------------------

1 - The user should be able to specify, for a given sort of exception, whether
    she wants to:

    a -	Throw the exception via the C++ mechanism, thus aborting unless she
	in the framework or a lower-level user responsible catchs the problem.

    b - Invoke a user-written handler when the exception occurs, which may
	itself determine it is necessary to throw the exception.

    c - Ignore the exception RETURNING TO THE SPOT IN THE ZOOM MODULE
	THAT DETECTED THE PROBLEM.  This can happen with or without a handler
	being invoked.  Typically, the module will then return some approriate
	pseudo-value to the user.

2 - In cases where exceptions are to be handled or ignored, there should be
    a well-known way to get information about the existance of a problem,
    analogous to the errno mechanism in C.

3 - Explanatory strings should be associated with the problem at the point
    of origin.

4 - The exceptions are organized in a hierarchical manner, which uniformly
    applies one simple category philosophy that the users can understand,
    across the various ZOOM packages.


With this in mind, our mechanism has the following structure:
- -------------------------------------------------------------


1 - Upon detecting a problem for which it would like to (potential) throw an
    exception, the module code will instead invoke the ZMthrow macro.

2 - ZMthrow takes as its argument a ZMexception object constructor, which
    has as ITS first argument a const char*.  The intent is for the ZMexception
    object actually to be derived from the base ZMexception class, and for
    the char* first argument to contain an explanatory message.  Particular
    ZMexceptions can also have construction forms taking a second string, or
    whatever.
    For example,
	ZMthrow ( HepTuple::ZMxCapture( "Column not found", name ) );

3 - The ZMthrow macro appends __LINE__, __FILE__ and calls ZMexcept.

4 - ZMexcept has signature

	template<class Exception> void ZMexcept
			( Exception x, int line,char file[]);

    It does the following:

    a - Places a copy of the exception object x into a circular buffer
        ZMerrno. More about ZMerrno later.

    b -	Determines for this exception what sort of logging is enabled, and logs
	it.  Note that derived exceptions must modify the general logging
  	method if they wish to include information beyond the message and
	file/line/time stamp.

    c - Determines whether the exception needs to be ignored, if so return

    d- Determines whether the exception a handler has been established, and
	if so invokes it.
	The handler will be passed the exception object, and can be set up to
	also take the line/file/time arguments.  The handler returns a bool
	which if true will say to throw the exception.

    e - Determines (after any handler has been invoked) whether to ignore the
	exception.  It will do either
		throw x;
	or
		return;

5 - ZMerrno is analogous to the C/Unix errno mechanism, but allows viewing a
    history of the last N problems detected.  We anticipate using it like errno,
    via exception id, but we copies of place the whole exception object onto
    ZMerrno to provide more info if desired.  The interface is:

    a - ((creation somehow, specifying N))

    b - ZMerrno.write (ZMexception& x);    // copy an exception onto ZMerrno

    The user would not use a and b but would use:

    c - string ZMerrno.read ();       // read the last id value on ZMerrno
	string ZMerrno.read (int k);  // read the last-but-k id value on ZMerrno

    d - void ZMerrno.clear();	   // put a zero (indicating no current error)
				   // on ZMerrno.

    e - void ZMerrno.pop();	   // remove an entry setting the top to the
				   // previous entry.  For instance, if you
				   // have a loop in which some known ignorable
				   // happening places a value on ZMerrno, you
				   // can pop each one so as not to wipe out
				   // the history for others.

    f - ZMexception* ZMerrno.get()      // Return pointer to the last or
	ZMexception* ZMerrno.get(int k) // last-but-k exception on ZMerrno.
					// Allows perusal of things like the
					// message and the logger and handler
					// used when the exception was
					// encountered.

    Thus after the start, or after ZMerrno.clear(), the user can always find
    out whether any ignored exceptions had occured by doing
	if (!ZMerrno.read().empty()) { ... then something has happened }

    If we later incorporate signal handling, this ZMerrno stack is where the
    user can find out whether he has had his arithmetic error since the last
    clear.

    ZMerrno is pronounced "oops."

6 - The id empty string indicates no error.  The id is a string representing
    the unique name of the exception class.

    Each ZMexception object class has its own error id which is established
    (hardwired) at construction.

7 - When a ZMexcept is thrown it does a ZMerrno.write(x).  Thus
    ZMerrno tracks these exceptions even if they are explicitly thrown and
    caught by the user outside the ZMthrow/ZMexception mechanism.

8 - Logging is discussed separately.

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

By the way, this is an interface for the framework manager to use; the lower
level user would generally never establish handlers or ignores, and would
only use the ZMerrno.read() and .clear().

1 - To establish a handler for a particular exception type, say for
    ZMexceptCapture:

	HepTuple::ZMxCapture.setHandler ( ZMhandler(myhandler) );

    	The handlerName string gives a convenient way to tell about the
	handling in log messages ("... was handled by mySuperHandler").

    The signature of the handler must be:
	bool myhandler ( ZMexception *x );

    We will have a ZMhandler class to contain that and the handlerName.

    Note that the handler has access to the fields of x including for all
    ZMexception objects:
		char* message;
		int line;
		char* sourceFileName;
		int serialNumber;
		ZMhandler* handler;
		ZMlogger* logger;
		// and class-wide data:
		static int id;
		static char* messagePreamble;
		static int count;
    and, for particular derived ZMexception objects, any secondary messages
    or other information provided to the constructor and kept in the object.

    The handler should return false to ignore the exception and return to
    the user code (from ZMexcept), or true to throw the exception after
    the handler returns.  The user can also throw an exception explicitly
    in the handler.

2 - You may establish a handler for an entire base class, which applies to any
    ZMexceptions derived from in that class for which no specific handler is
    established.  For example, HepTuple::ZMxNewColumn is derived
    from HepTuple::ZMxGeneral so

	HepTuple::ZMxGeneral.setHandler ( myDefaultHandler );

    will apply to HepTuple::ZMxNewColumn if that is ever ZMthrown.

2a- You may restore the previous handler by calling:

	HepTuple::ZMxGeneral.restorePreviousHandler();

    But set/restore do not implement a full stack:  You can freely do
    setHandler many times (or at the beginning of a loop for example)
    without leaking memory, even if you never restore.

3 - You can also use a deeper stack by using the following methods:

	HepTuple::ZMxGeneral.pushHandler(ZMHandler& Zh);
	HepTuple::ZMxGeneral.popHandler();

    If there is too many call to pop compared to the number of push, they
    simply will be ignored.

4 - Note that if a handler is established for a subclass it takes precedence
    over that for the base class.  If you instead wish to call the base class
    handler after executing the specific handler, you must invoke it
    explicitly.
    Only if no handler has been established will the exception check for and
    invoke a handler in its base class automatically.

5 - Four default handler types are provided:
       ZMHignore
       ZMHthrow
       ZMHparentHandler
       ZMHignoreNextN
    ZMHparentHandler is the default handler.  The default for the top most
    exception class (ZMexception) is ZMthrow.

6a- At times you may wish to prevent the calling of the parent class handler yet
    have no need for explicit handling.  In which case you would set the handler
    for this class to ZMHignore or ZMHthrow.

6b- The user can tell the system to whether or not to ignore an unhandled
    ZMexception (those methods are merely wrappers around less explicit calls
    to setHandler(ProperZmHandlerTypeForTheAction Zh)

	HepTuple::ZMxCapture.ignore()
	HepTuple::ZMxCapture.dontIgnore()
	HepTuple::ZMxCapture.default()

    The default is don't ignore -- meaning throw the exception unless a handler
    is invoked and comes back false.  The same rules for inheritance apply as
    in the handler case:  If you haven't specifically said anything about a
    subclass, then what you have said about the parent class will apply.  Thus
    calling dontIgnore() is NOT the same as not calling ignore().  In analogy
    with handling, we need a way to say "pretend I never said ignore or dont;
    use the parent class decision".  This is:

	HepTuple::ZMxCapture.setHandler(ZMparentHandler Zh)

7 - Sometimes you may want to ignore an exception the first N times and then
    react differently.  The handler can have a static count variable to
    implement this behavior.  Alternatively, there is a call to establish this
    behavior even if no handler is used:
	HepTuple::ZMxCapture.setHandler(ZMHignoreNextN(N) Zh)


The part of the interface seen by non-framework-manager users is simpler:
- --------------------------------------------------------------------------

1 - The ZMerrno methods may be used to see if (ignored) exceptions have
    happened.  Typically, the user used to Unix exceptions would call
    ZNerrno.read() and maybe ZMerrno.clear().

2 - The ordinary user can try, and catch, these ZMexceptions.  We ask that
    usrs not throw ZMexceptions that the ZOOM modules throw.  Later we may
    extend support to include user-defined subclasses of ZMexception.

3 - When an exception occurs and is not ignored, the user will know the
    message given for the exception, as well as the and line number where the
    ZMthrow macro was invoked.  This is inside ZOOM code.  By doing
    debug core <usersource> the user can get a traceback into the user
    routines to find which line of his code encountered the problem.

4 - The status of what was set up for ignoring and handling may be probed, so
    temporary control behavior can be set and then put back to what it was:

	const ZMhandler& handler() returns the established handler.
	const ZMlogger& logger()  returns the established logger.
								

Logging is handled as follows:
- ------------------------------

0 - The connection between a class of ZMexceptions and logging that is through
    a ZMlogger.  The (framework) user may create her own logger but typically
    will use our provided class ZMlog, which has is a ZMlogger and has a
    constructor taking a file name.  Any actions taken by the logger we
    describe below will refer to how ZMlog behaves.

1 - Every individual ZMexception object can have a method for creating
    (from the other arguments aside from messge) a string to put into a log.
    (Of course, it may be inherited from its base class.)  But the message
    as well as time, line, id, and so forth is not to be handled by each;
    instead, ZMthrow handles this.

    The method to create the string is logMessage().

    ZMexcept will at various points call the logThis() method of the established
    logger when it wants to log information.

1a- The user assgns a ZMlogger to an exception class by
	ZMexception::setLogger(ZMlogger*).
    For example,

	ZMlog mylog ("logfilename.txt");
	ZMxCapture::setLogger(mylog);

    The pointer returned should be checked.  In the case of ZMlog, it can be
    NULL for two reasons:  The file cannot be opened for append, or the file
    is already open for some other purpose.  (If it is already opened for
    logging, that is fine; this logger will also cause logging of messages
    there).

2 - ZMexception has a method setLogger(ZMlogger) which will open a log using
    that logger for that type of exception.

    This will establish this logger to be used for exceptions of this class.
    In the case of ZMlog, that means it will establish the file which was
    provided when the logger was constructed, as a logging point for
    exceptions of this class.  (This is class static information.)

2a- The ZMlog object will log to a file:  its constructor will open a log to
    that file for that type of exception.

    A user can provide a different logger which, for example, ties into the
    CDF or D0 general logging mechanism instead of writing to a file.

3 - If no logging is specified for a class the file defaults to the base class.
    Thus HepTuple::ZMxCapture might log to the file for HepTuple::ZMxGeneral,
    or if no logging is established there, for ZMexception.  It is possible
    (the default) that no logging is established anywhere.

4 - You may log to multiple files; each ZMexception (sub)class has a class
    static linked list of log files.

5 - Aside from single files, you can also establish a "rolling log" pair of
    files:
	ZMrollingLog mylog (const char filename1[], const char filename2[],
				int n );
	bool ZMexception::setLogger(mylog);

    The way this works is that the first file is opened (still for append),
    and up to n exception instances are logged into it, at which point
    it is closed, renamed to the second file, and re-created (empty) for
    more logging.  A script can detect when this has happended and archive
    the second file if desired.

6 - If you wish to cease logging a particular exception type in general or
    to a particular log file, you may:
	HepTuple::ZMxCapture.stopLog();
    If no exceptions are logging to a particular log anymore, that file will
    be closed.

7 - To be able to temporarily modify logging behavior for an exception, you
    may call
	setLogger(ZMlogger& newlog)
    and later call
	restorePreviousLogger()
    For a deeper stack you can also use:
	pushLogger(ZMlogger& newlog);
	popLogger();


The following shows how the above design can work
- --------------------------------------------------------------------

1. Each logger, handler and exception types will have a virtual Copy()
   method.  For example an handler class will have:
	  virtual ZMhandler* Copy() {
	    return new ZMspecificHandler(*this);
 	  }
   This will allow the exception class to create its own copy of each
   handler and logger of the correct actual type and not have to worry about
   external memory management.

2. The exception class contains the following functions:

	bool restorePreviousHandler();
	const ZMhandler& handler();
	bool popHandler();
	bool pushHandler(ZMhandler& Zh);
	bool setHandler(ZMhandler& Zh);

3. setHandler has the following signature:

  	setHandler ( ZMhandler& newHandler)

   and will execute at LEAST something like:

	delete _previousHandler;
	_previousHandler = _handler;
	[ZMhandler*] _handler = newHandler.Copy()

  This scheme insure us:
    Nobody can delete a used handler object.  handler object are only
    used in on exception class.  restorePreviousHandler implement a limited pop
    concept. (stack of size one).

4. The same concept applied to the logger classes and to the exception classes
   (for the benefit and ZMerrno).


The following usage recommendations pertain to writers of ZOOM code:
- --------------------------------------------------------------------

As shown in the examples, place your definitions of the exception objects
inside the class definition for the class.  That way, methods within this
class can simply call the shorter name -- ZMxCapture rather than
ZMxHepTupleCapture.

Don't create too many types of exceptions.  The error codes appearing on the
ZMerrno stack are defined per each type, but unless you envision the user
needing to AUTOMATICALLY distinguish between one problem and another in
the same submodule via ZMerrno, don't define them as two separate exception
types.

In cases where the user interface promises a routine will not throw an
exception (but might return false if something goes awry) the ZOOM code
itself should enclose any possible ZMthrows in try blocks, to catch the problem
in case the user has not specified ignoring the exception.

Note that the argument to the constructor of the ZMexception in ZMthrow can
(and often will) be a string formed by concatenating some fixed informatory
message with some variable information, as in
	ZMthrow ( ZMxCapture( "Column not found", name ) );
To do this, one should have a constructor for that sort of ZMexceptoin object
with the extra argument in its signature, as well as the one with just a
const char[].  One could alternatively do someting like
	ZMthrow ( ZMxCapture( strcat("Column not found", name) ) );
but if you use the exception in more than one place, the recommended second
constructor is less work.

When returning a pointer, in circumstances where things have gone wrong, the
usual action is to return a null pointer.  In many cases this is appropriate,
especially if the user interface defines it.  However, the sloppy user might
cause an (uncatchable) bus error if he does not check for null pointer.
Consider returning a pointer to a braindead object (whose methods throw
ignorable ZMthrows) rather than NULL -- then the job might not abort.


Documentation should be layered:

1 - How the user interacts with the mechanism (VERY brief).

2 - How the framework manager user interacts (settting up handlers, logs,
    ignores).

3 - How to define a ZMx class.

4 - Usage recommendations for writers of ZOOM code.