| Do Not | Return error codes. |
| Do | Report execution failures by throwing exceptions. |
| Consider | Terminating the process by calling System.Environment.FailFast (.net 2.0) instead of throwing an exception, if your code encounters a situation where it is unsafe for further execution. |
| Do Not | Use exceptions for the normal flow of control, if possible. |
| Consider | The performance implications of throwing exceptions. |
| Do | Document all exceptions thrown by publicly callable members because of a violation of the member contract (rather than a system failure) and treat them as part of your contract. |
| Do Not | Have public members that can either throw or not based on some option. |
| Do Not | Have public members that return exceptions as the return value or an out parameter. |
| Consider | Using exception builder methods. |
| Do Not | Throw exceptions from exception filter blocks. |
| Avoid | Explicitly throwing exceptions from finally blocks. |
| Consider | Throwing existing exceptions residing in the System namespaces instead of creating custom exception types. |
| Do | Create and throw custom exceptions if you have an error condition that can be programmatically handled in a different way than any other existing exception. |
| Do Not | Create and throw new exceptions just to have your team's exception. |
| Do | Throw the most specific (the most derived) exception that makes sense. |
| Do | Provide a rich and meaningful message text targeted at the developer when throwing an exception. |
| Do | Ensure that exception messages are grammatically correct. |
| Do | Ensure that each sentence of the message text ends with a period. |
| Avoid | Question marks and exclamation points in exception messages. |
| Do Not | Disclose security-sensitive information in exception messages without demanding appropriate permissions. |
| Consider | Localizing the exception messages thrown by your component if you expect your components to be used by developers speaking different languages. |
| Do Not | Swallow errors by catching nonspecific exceptions, such as System.Exception, System.SystemException, and so on in framework code. |
| Avoid | Swallowing errors by catching nonspecific exceptions, such as System.Exception, System.SystemException, and so on in application code. |
| Do Not | Exclude any special exceptions when catching for the purpose of transferring exceptions. |
| Consider | Catching a specific exception when you understand why it was thrown in a given context and can respond to the failure programmatically. |
| Do Not | Overcatch. Exceptions should often be allowed to propagate up the call stack. |
| Do | Use try-finally and avoid using try-catch for cleanup code. |
| Do | Prefer using an empty throw when catching and rethrowing an exception. |
| Do Not | Handle non-CLS-compliant exceptions (exceptions that don't derive from System.Exception) using a parameterless catch block. |
| Consider | Wrapping specific exceptions thrown from a lower layer in a more appropriate exception, if the lower layer exception does not make sense in the context of the higher layer operation. |
| Avoid | Catching and wrapping nonspecific exceptions. |
| Do | Specify the inner exception when wrapping exceptions. |
| Do Not | Throw System.Exception or System.SystemException |
| Do Not | Catch System.Exception or System.SystemException in framework code, unless you intend to rethrow. |
| Avoid | Catching System.Exception or System.SystemException, except in top-level exception handlers. |
| Do Not | Throw or derive from System.ApplicationException. |
| Do | Throw an InvalidOperationException if the object is in an inappropriate state. |
| Do | Throw ArgumentException or one of its subtypes if bad arguments are passed to a member. |
| Do | Set the ParamName property when throwing one of the ArgumentExceptions. |
| Do | Use value for the name of the implicit value parameter of property setters. |
| Do Not | Allow publicly callable APIs to explicitly or implicitly throw NullReferenceException, AccessViolationException, or IndexOutOfRangeException. |
| Do Not | Explicitly throw StackOverflowException. |
| Do Not | Catch StackOverflowException. |
| Do Not | Explicitly throw OutOfMemoryException. |
| Do Not | Explicitly throw InteropException, ComException, and SEHException. |
| Do Not | Catch SEHException explicitly. |
| Avoid | Deep exception hierarchies. |
| Do | Derive exceptions from System.Exception or one of the other common base exceptions. |
| Do | End exception class names with the “Exception” suffix. |
| Do | Make exceptions serializable. |
| Do | Provide (at least) these common constructors on all exceptions: 1. public SomeException(); 2. public SomeException(string message); 3. public SomeException(string message, Exception inner); 4. protected SomeException(SerializationInfo info, StreamingContext context); |
| Do | Report security-sensitive information through an override of ToString only after demanding an appropriate permission. |
| Do | Store useful security-sensitive information in a private exception state. |
| Consider | Providing exception properties for programmatic access to extra information (besides the message string) relevant to the exception. |
| Do Not | Use error codes because of concerns that exceptions might affect performance negatively. |
| Consider | The Tester-Doer Pattern for members that might throw exceptions in common scenarios to avoid performance problems related to exceptions. |
| Consider | The Try-Parse Pattern for members that might throw exceptions in common scenarios to avoid performance problems related to exceptions. |
| Do | Use the prefix “Try” and Boolean return type for methods implementing this Pattern. |
| Do | Provide an exception-throwing member for each member using the Try-Parse Pattern. |