Develop Reference

How to find which parts of C# code may throw exceptions

Is there a way to make Visual Studio tell me which parts of my code may throw exceptions? Something like the compiler warnings that can be suppressed, but instead it warns me that some line may throw an exception if it isn't surrounded by a try and catch.

No, there is no such functionality in VS.
C# (and .Net in general) does not support any kind of annotation to specify "method throws an interesting exception" (unlike Java, see Why are Exceptions not Checked in .NET?). As result there is no way to have general tool that will let you know that some "interesting" exception ( IOException as you've suggested) can be thrown from any given method.
In some cases VS/C# compiler can help. I.e. in C# 8 NRE actually has partial special treatment - "nullable reference type" which lets compiler to know if code expects null or not and warn at compile time if null passed where it is not supposed to.
Note: XML documentation (which is mentioned in comments as source of intellisense tooltips) is not part of code and there is no requirements for it to be correct/complete. Wast majority of the code does not have any useful XML documentation and documentation is not necessary available at compile time. So while it may serve as basis for some tool I don't believe VS is using it for any code highlighting.

ReSharper usually does that. It adds some warnings for possible exceptions.
If you don't want to use it search for similar products.

How can I find exception names (in intellisense) availible to throw in VS2008

One thing I find very frustrating with C# is when I find some issue and I want to throw a meaningful exception. I find it very difficult to find those exceptions in intellisense. There is no Exception namespace, so I cant list all exceptions via intellisense without digging around looking for the exception.
I am not looking to create my own exceptions, I am only trying to see if there are any other options than googling an exception to find its namespace so I can use it.

For the most part, this is bad practise. There are a small handful of exceptions that you should reuse (InvalidOperation, NullReference, ArgumentException, a few others). But you should not, for example, throw SqlException yourself - because you don't know what the framework might do with it.
Creating your own exception hierarchy adds meaning to your application at times of error. Reusing exceptions that have already-understood meanings leads to confusion - loss of meaning.

You can browse the entire Exception Class Tree in object Browser. Look for System.Exception and then click derived types. not 100% sure if all of them are there but the most of them are there for sure.
System.Exception -> Derived types (also in the root of the System.Excecption tree)

You can find some exceptions in the MSDN, here.
In general, these are the exceptions you'll ever tend to throw, and in many cases, you'll derive your own exceptions from these exceptions. However, a single method throwing too many different exceptions is generally frowned upon.
Also, recall the <exception> xml documentation tag. Using this tag goes a long way towards enlightening users which exceptions your method throws, and when. It's probably more important, in terms of clarity, than throwing exceptions of specific classes.

C# explicitly defining what exceptions are thrown

In Java, you explicitly define what exceptions are thrown using the "throws" keyword. That way, anyone calling your method knows what to catch.
Is there something in C#? If not, how do I know what exceptions to catch, or how do I let others know what exceptions to catch?
Also, if I am defining an interface, is there a way to say "methodX() should throw this exception on error"?

There is nothing equivalent in C#: The Trouble with Checked Exceptions
Other than documentation, there is no way to declare an interface to say "methodX() should throw this exception on error".

C#/.net does not have checked Exceptions, they proved to be less useful in large scale systems than first thought. In a lot of projects the time to maintain the check exception specs was a lot greater than the debugging time saved by having them.
Checked Exceptions seem like a good ideal until you have methods that can take delegates or calls into object you pass in. Take a simple case, the Sort() method on a list can’t know what exceptions it will throw, as it does not know what exceptions the Compar() method on the objects being sorted will throw.
So the spec for the exceptions a method may throw must be able to include information on how exceptions are populated from pass in objects and delegates. No one knows how to do this!
However there are tools that you check if you are catching all exceptions – see Exception Hunter by Red Gate. I personally don’t see much value in these tool, however if you like checked exceptions you may find them useful. ==> Looks like Exception Hunter wasn't too useful, so Redgate discontinued Exception Hunter a long while ago:

This feature is not available in C#. You can make proper XML documentation (3 slashes ///) and state what exceptions are being thrown.
This will be picked up by the IntelliSense mechanism and will be visible for the users of the class/method before they use it.

C# does not support this. (Not that I know anyway).
What you can do is use Xml Comments so that while calling you methods this data will be shown by intellisense.

As far as I'm aware there is no throws declaration in C# you can document your method indicating that it throws an exception but no forced error handling.

C# doesn't support checked exceptions. The language designers consider checked exceptions in the way java uses them a bad idea.
Some workarounds

Let me cite this medium article: It's almost 2020 and yet... Checked exceptions are still a thing
Among the many reasons why it's a bad idea, putting the checked exceptions in the contract (interfaces):
makes it impossible to change the implementation of an interface with a different one which throws different exceptions
exposes implementation details
a change of the checked exceptions of an API interface, makes it necessary to change the whole chain of interfaces in the call stack
For example, imagine that you are implementing a repository based on SQL Server, so you expose all kind of SQL Server specific exceptions. Then you want to move it to MySQL or Cosmos BD. Of course:
the implementation can't be changed to a new one that need to throw different exceptions. Also related to this, if you have different implementations of the storage, you can't just change them by configuration, but you need to have different compilations of the code for each storage backend
this is the explanation for 1: as the interface showed the implementation details (SQL Server exceptions) know you can't just change it
if you need to make the change, prepare to change the interface at all levels, since the API that uses the database up to the lates consumer in the call stack chain.
The articles cited above includes pointers to many explanations to discourage the use of checked exceptions, included this by the creator of C#: The trouble with checked exceptions

Automating documentation of Exceptions

In our solution we have a project that contains all the exceptions.
All of the exceptions inherit our base exception which inherits from ApplicationException.
Our base exception includes a field for exception number.
What I would like to do is to run a script that creates a list with exception name, number and xml documentation.
Any idea how to do this?

If you want to generate a list of the custom exceptions in your application, you can use XML comments for this task. See the accepted answer to this question. As far as I know, the comments will not be able to access the error number property, but you can add an XML comment to that property and state the error number there.

A "script" is not going to be able to do this. You need a static code analyzer that traces all the method calls and detects when an object that derives from Exception is created and thrown. It gets sticky when the code calls methods in the .NET framework, you don't have the source code for it. System.Reflection is no help, it cannot reflect code.
This ultimately goes back to why exception specifications are such a bad idea.
Redgate had a product named "Exception Hunter" to do this. But they gave up on it, couldn't make it reliable enough. The discontinuation announcement is here. Don't buy too much stock on them blaming .NET 4 for this.

How do I chose the most appropriate type of exception to throw?

There are already lots of questions on SO about exceptions, but I can't find one that answers my question. Feel free to point me in the direction of another question if I've missed it.
My question is quite simple: how do other (C#) developers go about choosing the most appropriate type of exception to throw? Earlier I wrote the following code:
if (Enum.IsDefined(enumType, value))
{
return (T)Enum.Parse(enumType, value);
}
else
{
throw new ArgumentException(string.Format("Parameter for value \"{0}\" is not defined in {1}", value, enumType));
}
I have since realised that throwing an InvalidEnumArgumentException would probably have been more appropriate had I known of its existence at the time.
Is there an authoritative resource available that helps developers chose exception types, or is it simply a matter of experience?
Edit
I've given the points to Noldorin for providing a range of ideas in a well thought-out answer. The points could have gone to any one of you really - thanks for all the suggestions.

Krzysztof Cwalina has a good post on this see chapter "1.1.1 Choosing the Right Type of Exception to Throw"
PS Consider subscribing to his blog. Good reading!
To answer your question: InvalidEnumArgumentException
because throw the most specific (the most derived) exception that makes sense.
AND callers that catch ArgumentException, catch InvalidEnumArgumentException too...

I would say it's just down to experience. There's still new exceptions I discover every so often, and I've been working with many aspects of .NET for a while now! What would you want this source to tell you, anyway? Choosing the appropriate exception type would seem highly context-specific, so I'm doubtful over the level of advice it could offer. Listing the more common ones would be most it could provide. The names and Intellisense descriptions of the exception types typically explain with good clarity their usage scenarios.
My recommendation is simply to familiarize yourself with all of the fundamental ones (specifically, those in System, System.IO, and any other namespaces you often use), and learn the others along the way. I find that I generally get away using just a small number. If you accidentally use a more generic exception type when there already exists a more specific one in the BCL, then it's no great crime, and can be changed later easily enough. To be honest, for any error that's particularly specific, you will often need to create your own class inheriting from Exception anyway.
Hope that helps.
Edit: If you want a brief guide to the very common ones, see the Common Exception Classes page on MSDN.

Common Exception Types and their Explanations
I think this will probably help you find out what the most appropriate exceptions for you to use are. You can also look into the MSDN documentation for more information on the Exception class and all of its types if you need.
MSDN Exception Class (System)
MSDN SystemException Class
(System) - More thorough list of
exception types

If you check out the MSDN article on System.Exception, right at the bottom of the page is a whole list of BCL exception types that inherit Exception. It's not quite a definitive list on what should be used for what - but it does give you a great place to start checking out exception types. Going through each will tell you what they should be used for:
http://msdn.microsoft.com/en-us/library/system.exception.aspx
There is also a fairly comprehensive article regarding the .NET Exception Hierarchy found at:
http://msdn.microsoft.com/en-us/library/z4c5tckx(VS.71).aspx
In fact the whole section in the MSDN library about handling and throwing exceptions is pretty good:
http://msdn.microsoft.com/en-us/library/5b2yeyab(VS.71).aspx

I have most of the common exceptions written on postcards on my desk and use them when people try and interop with me in a way that is exceptional.
This is really good practice for working out which exception fits best...
The one I find myself using mostly is OperationNotSupportedException

I think the real question is to ask yourself "What type of exception do I want to handle?" If you're not going to have special handling for an InvalidEnumArgumentException or an ArgumentException, then they offer no advantage over a plain old Exception.
I typically either throw Exception or wrap the exception in a custom exception.
Edited to add:
At one point, I recall that the guidance from Microsoft was that your application should never throw framework exceptions, rather it should only throw extensions of ApplicationException.

I usually define my own structure of exceptions, first creating some base exception:
class MyProjectNameException:Exception
{
...constructors, etc
}
and then derived classes for more precise exceptions. In this way you know exactly when to expect which exception, and you know if the exception was thrown by you or by the framework.

If you find an exception that is a good fit, you can use it.
If in doubt, just use ApplicationException. It's the exception that is intended for code that is not part of a standard library.
If the exception is not intended to be used in a standardised way (like catching the base class IOException to catch any I/O related error), the message that you put in the exception is more useful than the type of the exception.