Handling ReadBank error
BlitzMax Forums/BlitzMax Programming/Handling ReadBank error
| ||
The following code can crash even if doesn't over run the end of the stream. It crashes with the error "Error reading from stream". I know the data in the file I'm reading from is bad (the program crashed while writing it), and I also know the length it's trying to load is reasonable and there's enough ram. Why might readbank be crashing with ugly data, and how can I detect that or in some way stop the crash and just have it report back that the file is bad?Local pixBank:TBank = CreateBank(length) ReadBank(pixBank, stream, 0, length) |
| ||
This replacement function *should* prevent any screwups. It returns -1 if the stream doesn't exist 0 if it runs into the file's end before the length is complete 1 if everything went as expected. Function ReadBank:Int(bank:TBank Var,stream:TStream,offset:Long,count:Long) If Not stream Return -1 For Local read:Long=0 To count-1 If Eof(stream) And read<count Then Return 0 PokeByte bank,read+offset,ReadByte(stream) Next Return 1 End Function |
| ||
I'm already doing all those checks. I am reading plenty before the crash so I know the stream still exists, I check for remaining length before trying any read to ensure I won't hit the end... there's bad data caused by a crash during write and when I try to read through that space it crashes... I guess I could go byte by byte as in your example checking for EOF, but the stream should have plenty of length left so I doubt that would solve it... I don't really know why it crashes ultimately, because even with bad data it should just read the garbage... it's like the stream dies when you try to read through that area... |
| ||
if for some reason the system crashed before completely writing the file then there is a possibility that your hard drive is corrupted at a point in the file location. the problem with that is that if the Hard Drive TOC is pointing to an area where there is no data or is corrupt then the drive reports an error reading and is what you are getting. You can do a hard Drive error checking and repair. The possible problem is that you may loose or recover all of the data in that file, more of a chance that you will loose all of it. try at your own risk. I only mention it because that happened to me before and is not guarantee that it will solve your problem. I had a file reporting it was 1.5 GB when it was less than 1 MB |
| ||
It's not crashing.. it's throwing an exception, because the number of bytes returned by the Read() is less than it expected - i.e. it prematurely reached the end of the file. ReadBytes() throws the Exception. If you don't want to handle that, you can always implement your own reading to avoid ReadBytes altogether - I personally don't like the way it handles the streams in that method. Internally ReadBytes() calls Read(). You may want to call that method and handle the <> expected cases yourself. |
| ||
Haven't had time to try this, but if it's hitting a premature end, i.e. the file says it's longer than it really is (which makes sense) if I were to set the read point to the last point in the file and read 1 byte from there, that should return an error, as it's past the premature end... I could then handle that 1 byte read rather than re-writing all of my reads... in my case if a file is damaged I can afford to just throw it away, I just need to know it's bad so I can give up on it, rather that getting kicked out by the exception. |
| ||
maybe the program that wrote it screwed up the file info on the HD so the computer thinks it is longer than it really is? |
| ||
Use Try/Catch -- see this example. It's used many times there, but see the first function, GetBMPInfo. I used to it prevent my program crashing on unexpected stream ends and it works a treat, with no obvious slowdown. |
| ||
re: nate It did, that's the point, how to handle those situations without the program choking. re: james Thanks! I'll take a look, could save me much time. |
| ||
Question about try... If I have a try block in a method or function, and I return IN the try block is that going to cause bad things (because the try never reached it's end) or is it fine? |
| ||
Yeah, it's fine. |