R – How to find out what exceptions might be thrown by a .NET function

exceptionnetreference

I might be missing something obvious but is there a reference somewhere about what exceptions are thrown by functions in .NET and why the exception might be thrown?

As an example, I was recently trying out Linq in Visual C# 2008 and I was loading an XML file into an XDocument. It was only through testing that I realised that if you try to load a file that doesn't exist, it will throw a FileNotFound exception, but if you try to load a directory instead of a file you'll get an UnauthorizedAccessException. Also looking through the System.IO namespace I can see things like a FileLoad exception and a PathTooLongException, and I can guess when they might be thrown but there could be others out there that might be thrown in some circumstance I haven't thought of yet.

The only solution I've got right now is just to catch the ones I know about and then catch the Exception type, but I would rather be able to know exactly which types of exceptions I'm most likely to run into and why. I would have thought the MSDN library would have this type of information, but I can't find it anywhere. Am I just blind? Is this information anywhere else?

EDIT: Some more specifics, right now I'm looking for the exceptions that might be thrown by the XDocument.Load(string) function. It looks like there is nothing relevant in the online documentation or the object browser. Do I now have to just run some tests and see what I run in to?

Best Answer

Nice question, you have 20/20 vision. C#/.NET does not implement the throws statement (i.e., checked exceptions).

Anyone coming from a language such as Java is likely to wonder about this.

Anders Hejlsberg, the father of C#, explains the rationale behind leaving checked exceptions out of C# in this article/interview. It's a good read.

From that article, Anders says:

The concern I have about checked exceptions is the handcuffs they put on programmers. You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any. It is sort of these dictatorial API designers telling you how to do your exception handling. They should not be doing that.

So, as Mitch and monoxide have said, MSDN documentation for the .NET FCL lists exceptions relevant to each class and also exceptions possible within each namespace.

Related Topic