In C#, are there any built-in exceptions I shouldn

问题:

Are there any Exceptions defined in the .NET Framework that I shouldn't throw in my own code, or that it is bad practice to? Should I write my own?

回答1:

You shouldn't throw any exception that is automatically thrown by the CLR due to user errors. For instance

• StackOverflowException
• NullReferenceException
• AccessViolationException
• etc ...

The reason being is to do so creates confusion for people calling your API. Users should be able to distinguish between actively thrown exceptions by an API and exceptions that are not actively thrown (thrown by CLR).

The reason is that at actively thrown exception generally represents a known state in an API. If I call an API and it throwns an ArgumentException, I have a reasonable expectation that the given object is in a good state. It recognized a potentially bad situation and actively accounted for it. On the other hand if it throwns a NullRefrenceException, that is an indication that the API encountered an unknown error and is now in an unreliable state.

Another lesser reason is that these exceptions behave differently when thrown by user code as opposed to the CLR. For instance it's possible to catch a StackOverflowException if thrown by user code, but not if it's thrown by the CLR.

• http://blogs.msdn.com/jaredpar/archive/2008/10/22/when-can-you-catch-a-stackoverflowexception.aspx

EDIT Responding to Michael's comment

You also should not throw Exception, ApplicationException or SystemException directly. These exceptions types are too general to provide meaningful information to the code which calls your API. True you can put a very descriptive message into the message parameter. But it's not straight forward or maintainable to catch an exception based on a message. It's much better to catch it based on the type.

FxCop rule on this subject: http://msdn.microsoft.com/en-us/library/ms182338(VS.80).aspx

回答2:

Most exception classes in the framework are not meant for reuse since they usually are crafted to signal some Framework specific error. Like those mentioned by @JaredPar, they are used by the framework to indicate certain states in the framework.

There are literally tens, maybe hundreds, exceptions in the framework, so IMO it is more useful to list those that we should use. At the top of my head, these are those I actively use:

• ArgumentException, ArgumentNullException and ArgumentOutOfRangeException
• InvalidOperationException
• NotSupportedException
• NotImplementedException

For other error conditions in user code, best practice is to create your own exception classes.

回答3:

@Michael There is actually one situation in which it is recommended to throw a NullReferenceException: If the first parameter (the "this" parameter) of an extension method is null. You need to do this in order that null variables behave as expected.

回答4:

Microsoft was at one point telling programmers not to inherit directly from Exception, but instead to use ApplicationException as their base class. Not sure if that opinion still holds true, though...

And if a pre-defined exception already exists that covers your exact error condition (like "NullReferenceException", or "InvalidArgumentException" etc.) - by all means, throw those instead of re-inventing them inside your own code.

Marc

回答5:

there are several exception already defined for you. Always try to use these Exceptions before roll your own

回答6:

The online Design Guidelines for Exceptions contains the principle advice (see specifically this page).

The book "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition" has more details and more discussion on this topic.