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
|