Hello,
I maintain an application that pulls data from a web service and writes
it to an Excel sheet. Originally, the app used OleDb to write the
Excel. Exports ran fine except that some text fields were truncated due
to the 255 character limit of the Jet Excel driver. To overcome this
limit, I decided to just generate CSV directly. This is where my
trouble began.
First I tried the StreamWriter class, implemented as per the "How to:
Write to a Text File" MSDN example
(http://msdn2.microsoft.com/en-us/library/6ka1wd3w.aspx).
Then I tried the FileStream class, implemented as per the example from
the MSDN class entry
(http://msdn.microsoft.com/library/de...ClassTopic.asp)
With both classes, the app would throw a NullReferenceEx ception at an
arbitrary point of the export. Sometimes it would happen on the 400th
record, sometimes on the 1250th, etc. The reason I say it is an
uncatchable exception is because of my work with the debugger. Here is
the chunk of code that the debugger points to when it throws the
exception in debug mode:
For p As Integer = 1 To totalPages ''main record loop
''---
''EXPORT CODE HERE
''---
Catch ex As Exception
swrLogFile.Writ eLine("Error while processing Item:")
swrLogFile.Writ eLine(ex.Messag e)
swrLogFile.Writ eLine(ex.StackT race)
swrLogFile.Writ eLine("") <<========debug ger points here as source
of exception
End Try
Next
I set a breakpoint on the first line of the Catch block to see what
exception it was catching. It never hit the breakpoint. Just jumped
straight to the last line of the Exception block, as shown.
Technically, this seems impossible, so I began to suspect that the
NullReferenceEx ception was just confusing the debugger and it was
pointing to a somewhat arbitrary point in the code.
I then added the following code to test this theory and make sure that
it wasn't my log file StreamWriter that was crashing:
For p As Integer = 1 To totalPages ''main record loop
''---
''EXPORT CODE HERE
''---
Catch ex As Exception
Try
swrLogFile.Writ eLine("Error while processing Item:")
swrLogFile.Writ eLine(ex.Messag e)
swrLogFile.Writ eLine(ex.StackT race)
swrLogFile.Writ eLine("")
Catch ex2 as Exception
End Try <<============= =debugger points here as source of exception
End Try
Next
The test confirmed that the debugger is just jumping to the end of the
catch block for lack of a more accurate place to point.
I've worked with many debuggers that do this frequently; newer MS
debuggers are pretty good at pinpointing the actual source of an
exception, but in this case I think it is failing to do so.
To recap:
a) I am almost 100% positive this is a problem with the managed FileIO
because the code was working fine before I began writing the data
directly to file (vs. through the OleDb driver) and nothing else
changed
b) I have no way of diagnosing and working around this problem because
the compiler fails to give me any useful information about the
exception.
Please help if you can.
Thanks,
-Paul
