Best Practices for C# Exception Handling

The C# error handling knowledge pack contains preconfigured rules based on the .NET Error Raising and Handling Guidelines found in Microsoft's C# Design Guidelines for Class Library Developers, .NET Best Practices for Handling Exceptions found in the .NET Framework developers guide as well as other industry best practices.  These rules are highly configurable and offer the ability to define your own best practices.

 

Rule	Description	Automatic Correction
Handled Exceptions should be published	When exceptions are handled in try catch block, the information should be published to a system log and/or to the user.  This rule detects and implements publishing based on your needs.  These include EventLog, AssertDebug, MessageBox.Show and Microsoft's Exception Management Application Block as well as custom event publishing methods.	Yes
Specific call requires a try/catch block	Enforces the requirement that certain calls have a try/catch block around them.  This rule allows you to define under what circumstances you should use a try/catch block.  Examples include references to certain objects, calls to certain methods or encapsulating specific methods with centralized exception handling.	No
Method requires tracing implementation	Enforces the requirement that specific methods have enter/leave tracing implemented.  This rule makes it easy to completely add or remove instrumentation from your solution using the Trace class.	Yes
ArgumentException should be used if invalid parameters are passed.	Exceptions of type System.ArgumentException should be thrown when an invalid argument has been passed into a method.  These include: System.ArgumentException System.ArgumentNullException	Yes
Do not create methods that throw IndexOutOfRangeException	System.IndexOutOfRangeException is a system exception thrown only by the runtime and should not be thrown by application code.	Yes
Do not create methods that throw System.Exception	System.Exception is a base class for subclassing all exceptions and should therefore not be used directly.	Yes
Do not create methods that throw System.NullReferenceException	System.NullReferenceException is a system exception thrown only by the runtime and should not be thrown by application code.	Yes
Do not create methods that throw System.Runtime.InteropServices.ExternalException	ExternalException is a base class for subclassing COM Interop exceptions from and should therefore not be thrown directly.	Yes
Do not create methods that throw System.SystemException	System.SystemException is a base class for subclassing all system exceptions and should therefore not be thrown directly.	Yes
Localize strings for any exception messages	Localize any public facing exception strings by putting the message strings in a resource file.  This rule will automatically localize the string, create the resource and make the call to Resources.ResourceManager	Yes
Test for Null argument before referencing	It is good practice to test method arguments for null before referencing, and if they are null throw an ArgumentNullException.  This can provide more detailed information in cases where an unexpected error occurs.  If this is not done the exception may be a NullReferenceException with very little information available.	Yes
Re-throw should not throw with argument.	Do not re-throw the same exception using the exception argument in the throw statement.  A try catch block that throws with the argument causes the loss of the original stack trace when the Exception.StackTrace method is called.	Yes
Exception class names must end in the word "Exception"	Exception classes, those that inherit either directly or indirectly from System.Exception, should be suffixed with the word "Exception".  This rule understands common misspellings and other suffixes such as "Error", "Warning", etc.	Yes
Exception classes Must Be Marked Serializable	In order to work properly in all scenarios, user-defined exceptions must be serializable and have the System.Serializable attribute.	Yes
Should not inherit directly from System.Exception	System.Exception is a base class for subclassing all exceptions in the .NET framework and should not be inherited from directly to create user-defined exceptions.	Yes
Should not inherit indirectly from System.SystemException	System.SystemException is a base class for subclassing all system exceptions in the .NET framework and should not be inherited from directly to create user-defined exceptions.	Yes
Use the three common constructors when creating Exception classes	It is a good practice when creating user-defined exception classes to implement the three common constructors.	Yes

转载于:https://www.cnblogs.com/yefengmeander/archive/2011/09/05/2887682.html