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