Hi Konstantin et al, On Sun, 21 Jan 2001 11:31:54 -0500 Konstantin Olchanski <olchansk@ux1.phy.bnl.gov> wrote concerning ": module statuses (was Re: BRAT changes)": > Christian, I think the module status, as currently proposed, is ill defined. Ok. > Instead of vague verbal descriptions, such as "ok", "error", > "bad error", "very very bad error", we should give a functional > definition of what happens to the event processing when a module returns > a given status. Then we can name the statuses according to what they *do* > and the module writers would know what to return when. Right. Trust the CS Ph.D. to come up with the right thing. Thanks Konstantin. > Only 4 things can happen depending on the module status: > > 1) the next module in the pipeline is invoked. Call this the "ok" > status. Or BrModule::kOk. > 2) the event processing stops normally. This could be returned by a trigger > latch filter module. Call this the "stop" status. Or BrModule::kStop > 3) the event processing stops with an error. This could be returned a module > to signal a problem with the event, for example missing or invalid > input data, or a transient internal error. Call this the "error" status. Hmm. kError doesn't work, since that symbol is already used by ROOT. Scoping it within BrModule as BrModule::kError does help, but will be confusing to most, and I'd like it to have a numerical value other then ::kError. Hence I'd like another name, say BrModule::kFailure > 4) the whole application stops. This could be returned by a module > when further processing is meaningless or dangerous, > and is returned as an alternative to calling exit(), abort() or assert(). Ah. No BRAT code should contain the function calls exit(), abort(), or assert() directly. Use TObject::Fatal() instead. For assert(), use ROOTs Assert from TError.h. > Examples are: missing calibration data, corrupted private data, This is for BRAT proper to deal with. > gross system malfunction (2+2 produces 5 or sin(x)>1, sometimes happens > when using -O compiler switches or porting code to Alpha and x86 CPUs). This however, may just as well be accomplished via TObject::Fatal. In fact, it should be. > Call this "abort" status. Or BrModule::kAbort Using these values, there should be no real need for user modules to define thier own exit status, I think. Any comments? Yours, Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Sun Jan 21 2001 - 12:08:10 EST