From pcanal@fndaub Wed Jul 9 16:17:45 1997 > > I thought handler(whatever) was the routine that establishes the handler. > Yes, we can distinguish the two by signature, but to me that feels like > having a write(val) and a value=read() method, only calling the read method > value=write(). Possible but not as clear. I agree with this point ... so settling for setHandler() and handler() seems appropriate From mf Wed Jul 9 14:02:47 1997 Philippe Canal writes: > > >> 4 - The status of what was set up for ignoring and handling may be probed, so >> temporary control be havior can be set and then put back to what it was:> >> >> GetHandler() returns the estabished handler (and we have to decide how >> to cope with the two different handler signatures!!).>> >> >> int ignoreStatus(); // 1 - ignore was specified >> // -1 - dontIgnore was specified >> // 0 - neither was specified; use status from >> // parent >> void setIgnoreStatus(int); > >A few comments: > >the documents may (or may not) need to be updated in its ealier part ( >it talks about the ignore() and dontIgnore() methods). > I think it is OK there. >the return ignoreStatus() returns may be more flexible with the following >semantics: > -1: always ignore > 0: don't Ignore > 1-999999: ignore this number of times. > I prefer to let the user set up "ignore this number of times" by having a handler. However, perhaps our "ignore" concept should be extended to include a possibility meaning "ignore completely without even calling handler". In that case, modifying the ignore and dontIgnore() methods to control this would be sensible. >Comestically (unless ZOOM has any other standard) GetHandler might just >as well be called handler(). > I thought handler(whatever) was the routine that establishes the handler. Yes, we can distinguish the two by signature, but to me that feels like having a write(val) and a value=read() method, only calling the read method value=write(). Possible but not as clear. >It should be make clear where handler() and ignoreStatus return the >information contained in the current class OR the information that will be >actually used for the class (those two will be different if the a top class >have been set while the sub class has not). Good point. The intent was the info in the current class. But maybe there needs to be a method for the other. > >I dont remember if the document explained what happen if: > >HepTuple::ZMxGeneral::handler() == MyGeneralHandler() >HepTuple::ZMxCapture::ignoreStatus() == don't ignore .... >HepTuple::ZMxCapture::handler() == NULL > >If I ZMthrow a HepTuple::ZMxCapture is going to: > run MyGeneralHandler() I did not think about establishing a NULL handler explicitly. Probably the way to establish a trivial handler just to prevent the invoking of a parent handler is to make one and set the handler to that, rather than to use NULL. The way I had it, the above code WOULD call MyGeneralHandler, but I don't know this is the right way to work it. > throw a HepTuple::ZMxCapture:: Should do so only if MyGeneralHandler() returns true. >How to I tell force it to throw a HepTuple::ZMxCapture:: ? write a handler that always returns true. Or have a trivial handler (or no handler up the line) and set the dontIgnore. I RAN OUT OF TIME TO ANSWER REST OF THIS, WILL ANSWER LATER. >Do I need to set an handler that returns false ? > >In a more general sense what is the interaction/precedence of >the ignoreStatus and the handler pointer > >Do we still have two different handler signatures ? > >Philippe. > From pcanal@fndaub Wed Jul 9 13:32:43 1997 > > No, according to Mengel there are some circumstances in which it misbehaves a nd > others where it is OK. > Do we know the circunstance where it does not misbehave ? From pcanal@fndaub Wed Jul 9 12:02:43 1997 Status: RO Hi, I suspect that you are aware of the fact that as of gcc 2.7.2, exception do not work on MIPS platforms. (actually it just ignore the throw). Philippe Canal, pcanal@fnal.gov, 630-840-2545. From pcanal@fndaub Wed Jul 9 16:17:45 1997 d handler() seems appropriate From pcanal@fndaub Wed Jul 9 11:12:43 1997 > 4 - The status of what was set up for ignoring and handling may be probed, so > temporary control be havior can be set and then put back to what it was:> > > GetHandler() returns the estabished handler (and we have to decide how > to cope with the two different handler signatures!!).>> > > int ignoreStatus(); // 1 - ignore was specified > // -1 - dontIgnore was specified > // 0 - neither was specified; use status from > // parent > void setIgnoreStatus(int); A few comments: the documents may (or may not) need to be updated in its ealier part ( it talks about the ignore() and dontIgnore() methods). the return ignoreStatus() returns may be more flexible with the following semantics: -1: always ignore 0: don't Ignore 1-999999: ignore this number of times. Comestically (unless ZOOM has any other standard) GetHandler might just as well be called handler(). It should be make clear where handler() and ignoreStatus return the information contained in the current class OR the information that will be actually used for the class (those two will be different if the a top class have been set while the sub class has not). I dont remember if the document explained what happen if: HepTuple::ZMxGeneral::handler() == MyGeneralHandler() HepTuple::ZMxCapture::ignoreStatus() == don't ignore .... HepTuple::ZMxCapture::handler() == NULL If I ZMthrow a HepTuple::ZMxCapture is going to: throw a HepTuple::ZMxCapture:: run MyGeneralHandler() How to I tell force it to throw a HepTuple::ZMxCapture:: ? Do I need to set an handler that returns false ? In a more general sense what is the interaction/precedence of the ignoreStatus and the handler pointer Do we still have two different handler signatures ? Philippe. From pcanal@fndaub Tue Jul 8 14:17:39 1997 > > I think you are right. The first argument should be a ZMexception&. Then > when we do > class ZMxCapture : public ZMexception { ... } > : > : > ZMexcept ( ZMxCapture ("a message"), line, file, data, time ); > > And > ZMexcept ( ZMexception &x, int line, > char file[], char data[], char time[]) { > : > : > throw x; > } > > this will (I think) throw the ZMxCapture. If not, we will need to make it > a ZMexception* and do: > > class ZMxCapture : public ZMexception { ... } > : > : > ZMexcept ( *ZMxCapture ("a message"), line, file, data, time ); > > And > ZMexcept ( ZMexception *x, int line, > char file[], char data[], char time[]) { > : > : > throw *x; > } > > which is less elegant but may be necessary. Actually I think the right solution is to have ZMexcept being a template: template void ZMexcept ( exception x, int line, char file[], char date[], char time[]);