Hi Dave, I agree with what you say. I will investigate why TTree::GetEntry does not return 0 in the case you report. Note that you can already trap all Root errors via the message handler. Root implements a default message handler TMessageHandler. You are free to derive your own class from this default class. see : http://root.cern.ch/root/htmldoc/TMessageHandler.html Rene Brun Dave Casper wrote: > > Hi, > > I have data which was written to a removable disk, a few sectors of which > appear to be (or have become) bad. When reading the file, I get the > following error message on the screen: > > R__unzip: error during decompression > Error in <TBasket::Read>: fObjlen = 2497941, nout = 0 > > (There is no "TBasket::Read" method; the message in question actually comes > from TBasket::ReadBasketBuffers). My program crashes (not surprisingly) > when trying to process the event in question, probably because some chunk of > the data is missing. > > I am wondering if there is any way to handle such an error more gracefully. > Currently I check the return status of TTree::GetEntry. About all I know to > do is check whether the number of bytes read is zero, since I don't know > what the number of bytes which *should* be read is. That fails to catch > this error. I don't see any way to tell whether such an error has occurred. > It would seem to me that if there is an error, TBasket should invalidate the > current operation and return zero bytes. This should (naively) filter up > through the system such that TTree::GetEntry also returns zero bytes and > there is some way to determine that an error occurred during the call. > Alternatively, perhaps some status flag could be set if an error occurs at > any point during the operation, which I could check in addition to the > number of bytes read. All that is really needed is for Root to set some > flag when an error is detected. The user could be responsible for clearing > the status flag before any operation he wants to handle errors from, and > checking to see if it is set afterward. > > Of course, one hopes that such errors occur infrequently, but they will > happen from time to time, and it seems drastic if there is no way to detect > them and continue. One of the nice things about having a direct access file > format is that corruption of a small part of a file shouldn't prevent the > other parts of it from being read. > > Is this type of error flagging something which could be added? It seems a > shame to detect an error and print a message on the screen but provide no > way for the caller to know that it has occurred. > > Dave > dcasper@uci.edu
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:40 MET