Hi Flemming, Djam, and other BRATs, On Sat, 20 Jan 2001 15:16:03 -0500 "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning ": Re: BRAT changes (filter)": > I will like to second the opinion voiced by Djamel. The result of a > filtering is the normal action of the module not a disaster, > problems etc. That's true. > The module could still have this going on but this is differentger > (e.g. the trigger word not present). Also does this philosofy match > the error messaning? Damn - I really liked the word "Disaster" for it, but I guess it wasn't that descriptive. Well, I sort of anticipated these reponses, but "kDisaster" has such a nice ring to it (and it makes me smile to write it in the code!). Well I gave this a few thoughts this morning, and I think I've come up with some that should fulfill your (and my) wishes. At the moment, the fStatus member of BrModule is of type enum EBrModuleStatus { kOk = ::kWarning - 100, // Module is doing fine kProblem = ::kWarning + 100, // Module had some problems, not serious kFailure = ::kError + 100, // Module failed, not too seriously kDisaster = ::kError + 200 // Module failed miserably }; That means, that the fStatus member can only take the values kOk, kProblem, kFailure, and KDisaster. Since I thought a failure should not nessecarily break the module pipeline, I made BrTriggerFilter send kDisaster to the container. However, If we instead made fStatus a Int_t (or UInt_t), and had const Int_t BrModule::kOk = ::kWarning - 100; const Int_t BrModule::kProblem = ::kWarning + 100; const Int_t BrModule::kFailure = ::kError + 100; cosnt Int_t BrModule::kDisaster = ::kError + 200; the user modules could define additional fStatus conditions, like const Int_t BrTriggerFilter::kVetoTrigger = kFailure + 1; const Int_t BrVertexFilter::kVetoVertex = kFailure + 2; const Int_t BrTrackFilter::kVetoVertex = kFailure + 3; (of course, it'd be the module writers responsobility to make these numbers unique - a clash would be very confusing.) If we so desired, we could then change the error handler routine from the default ROOT one, to one that can access a list of messages, based on some registered number and string, but I think that maybe overdoing it. and the BrModuleContainer could do while((module = (BrModule*)next())) { module->[Init|Begin|Book|Event|End|Finish](); if (module->GetStatus() >= kDisaster) { Fatal("[Init|Begin|Book|Event|End|Finish]", "Disaster in module %s", module->GetName()); return; } if (module->GetStatus() > kFailure) { // Break module pipeline if (Verbose() > kShowFailures) Failure("[Init|Begin|Book|Event|End|Finish]", "Module %s got status %d", module->GetName(), module->GetStatus()) else SetStatus(kFailure) break; } } or some thing like that. However, I should point out, that one still has the ROOT methods Warning, Error, Fatal at ones disposal. In particular Fatal will cause the application to SIGABRT (abort - core dump). As far as error messages is concerned; that up to the module writer. The methods Problem, Failure and Disaster can help you with this. In a sense, we really don't have to change anything, other then you interpretation of "Disaster"! But I can see that It may be misleading, so I'm open to something else like kVeto. 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 - 09:28:54 EST