So today was a Woot-Off. The detector sort of worked – when I plugged it in, it quickly detected and turned on the lights. However, after a new product it completely stopped working and was throwing IndexOutOfRange and OutOfMemory exceptions. Turned out that there are some weird limitations in the StreamReader class. Originally the code would continue to ReadLine() until there was nothing left to read. However, some of the lines in the RSS feed were extremely long and would blow the buffer and throw. I then rewrote the code to just use Peek() and Read() one char at a time to fill a 256 char array. This also started to throw an IndexOutofRangeException on subsequent Peek() calls; the problem here was the internal buffer is 512. For some reason that I haven’t figured out yet, that 512th Read() caused the problem. Ok, now what?
After reading the documentation, I found this interesting tidbit:
If the current method throws an OutOfMemoryException, the reader’s position in the underlying Stream object is advanced by the number of characters the method was able to read, but the characters already read into the internal ReadLine buffer are discarded.
Hmmm. So basically, if I hit an OOM then I should be able to just continue to read from the stream from where ever it blew chunks. And this is fine because the liklihood of this barfing on a line that I care about (i.e. <woot:product> or <woot:wootoff>) is damn near close to nil. I gave it a shot and it seems to be working fine now.
Too bad I didn’t figure this out earlier. We could have used this today. 😦