Hi Paolo, We are currently working on the implementation of a TMessageHandler class. This class should be the solution to the problem you describe. You can implement your own class derived from TMessageHandler and have several instances of this class. In the Notify method of this class you have access to the object generating a message (or error) and you can take some action at this point. For example when filling a Tree with branches going to different files, you may want to automatically assign a new file when the size of the current file is reaching a certain limit. At the same time, this new class can be used to monitor the occurence of some particular messages/errors/warnings, etc. The Print method can be used to print a summary, eg at the end of the job. We expect to have this class implemented for the coming release. The same mechanism could also be used when C++ exception handling will be generally available (and working). Rene Brun pcalafiura@lbl.gov wrote: > > Hi rooters, > I am putting together an output module that writes large amounts of data > in a TTree. I want to check for error conditions (like a disk that fills > up). > Looking at the signature of TTree::fill(), that returns an int with > the number of bytes written, I was assuming that an error condition > would have been flagged returning 0 or a negative number. Not so! > That's what I get: > > ..... > SysError in <TFile::WriteBuffer>: error writing to file > data93/calaf//DIMblock_1/small2_stream_941832479_temp_0 (No space left on > device) > SeqRootDiskFile::write: bytes written 23019 > ..... > > this goes on till the end of the job, the files are closed properly and > if you don't look at the logs you'll never notice that something went > wrong! > > This is how I understand what's happening: > TFile::WriteBuffer sees the error condition, prints an error message > and returns an error code. But the error code is ignored by the > intermediate level in TBasket class so TTree::fill doesn't have a > clue that something is wrong. There is some logic into that: TTree::fill() > is not writing to disk but into the memory buffer so strictly speaking the > error is not its business. Having said that, > what can the poor programmer do if he wants to handle this error? > > If, for example, there were a TFile error condition flag (a sort of > errno) that I could check before filling the tree, I could > disable writing to the faulty stream or simply stop the job with an > error code... > > Any suggestion? > > Paolo Calafiura >
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:42 MET