It is because you have not written
xDoc.Load(File.FullName);
inside the try block. That is the reason why the exception was not handled.
rahul
2009-09-10 10:20:38
+3
A:
That's it, thanks! But could you explain (or point to somewhere) why is this the case?
Sk93
2009-09-10 10:27:00
You can catch an exception only if it occurs in a try block corresponding to the catch block.
rahul
2009-09-10 10:28:09
But the line that was throwing the error (.SelectNodes) was within the try catch.. But I think I know now; does the XMLDocument object use lazy binding?
Sk93
2009-09-10 10:30:26
+2
A:
The other answer about putting Load() inside the try block is right, but doesn't actually explain why SelectNodes() "appears" to be throwing an XmlException that is not being caught.
The actual answer is that the debugger is confused/out of sync with your source code and is actually showing the wrong line as causing the exception.
It should really be pointing to the xDoc.Load(File.FullName); , in which case it would be clear that this call should be inside the try block.
Why? Notice the XmlLoader.LoadNode() in the last line of the stack trace. In .NET Reflector you can see that the XmlDocument.Load() method (deep in it's bowels) calls the LoadNode() method.
However, also in reflector, it can be seen that the SelectNodes() method does not call LoadNode() anywhere in it's internal implementation.
So according to the stack trace, the exception cannot have been caused by SelectNodes().
I've seen the debugger get confused like this before when a code change is made and debugging started, but the debugging symbols have not been updated correctly. Try cleaning and re-building your solution to refresh the debugging symbols.
Ash
2009-09-10 14:07:52
I've rebooted, cleaned the solution, rebuilt and retested and it still fails on the "wrong" line.Yet stick the lines within the try catch and step through it, it breaks on the "load" line.. odd
Sk93
2009-09-10 14:19:22