CA1065: Do not raise exceptions in unexpected locations
TypeName | DoNotRaiseExceptionsInUnexpectedLocations |
CheckId | CA1065 |
Category | Microsoft.Design |
Breaking Change | Non Breaking |
Methods that are not expected to throw exceptions can be categorized as follows:
-
Property Get Methods
-
Event Accessor Methods
-
Equals Methods
-
GetHashCode Methods
-
ToString Methods
-
Static Constructors
-
Finalizers
-
Dispose Methods
-
Equality Operators
-
Implicit Cast Operators
The following sections discuss these method types.
Property Get Methods
Properties are basically smart fields. Therefore, they should behave like a field as much as possible. Fields do not throw exceptions and neither should properties. If you have a property that throws an exception, consider making it a method.
The following exceptions are allowed to be thrown from a property get method:
-
System.InvalidOperationException and all derivatives (including System.ObjectDisposedException)
-
System.NotSupportedException and all derivatives
-
System.ArgumentException (only from indexed get)
-
KeyNotFoundException (only from indexed get)
Event Accessor Methods
Event accessors should be simple operations that do not throw exceptions. An event should not throw an exception when you try to add or remove an event handler.
The following exceptions are allowed to be thrown from an event accesor:
-
System.InvalidOperationException and all derivatives (including System.ObjectDisposedException)
-
System.NotSupportedException and all derivatives
-
ArgumentException and derivatives
Equals Methods
The following Equals methods should not throw exceptions:
An Equals method should return true or false instead of throwing an exception. For example, if Equals is passed two mismatched types it should just return false instead of throwing an ArgumentException.
GetHashCode Methods
The following GetHashCode methods should usually not throw exceptions:
GetHashCode should always return a value. Otherwise, you can lose items in the hash table.
The versions of GetHashCode that take an argument can throw an ArgumentException. However, Object.GetHashCode should never throw an exception.
ToString Methods
The debugger uses Object.ToString to help display information about objects in string format. Therefore, ToString should not change the state of an object and it should not throw exceptions.
Static Constructors
Throwing exceptions from a static constructor causes the type to be unusable in the current application domain. You should have a very good reason (such as a security issue) for throwing an exception from a static constructor.
Finalizers
Throwing an exception from a finalizer causes the CLR to fail fast, which tears down the process. Therefore, throwing exceptions in a finalizer should always be avoided.
Dispose Methods
A IDisposable.Dispose method should not throw an exception. Dispose is often called as part of the clean up logic in a finally clause. Therefore, explicitly throwing an exception from Dispose forces the user to add exception handling inside the finally clause.
The Dispose(false) code path should never throw exceptions, because this is almost always called from a finalizer.
Equality Operators (==, !=)
Like Equals methods, equality operators should return either true or false and should not throw exceptions.
Implicit Cast Operators
Because the user is often unaware that an implicit cast operator has been called, an exception thrown by the implicit cast operator is completely unexpected. Therefore, no exceptions should be thrown from implicit cast operators.
When using automatically "Implement Interface" feature, it generate functions and properties with "throw new NotImplementedException()".
But properties is not allow to throw NotImplementedException by this rule.
If implement properties with another Exception like NotSupportedException, then the next question is why functions still throw NotImplementedException?
So you should either adjust this rule to allow property to throw NotImplementedException, or implement functions and properties all with another Exception like NotSupportedException.
- 5/25/2012
- ChrisTorng
[Patrick-MSFT]
Hi,
The MSDN Library community content is designed primarily to enable MSDN users to provide feedback, extensions and explanations of the documentation. It is not a good way to have issues with the code analysis rules themselves addressed. To discuss the implementation of code analysis rules, post your questions or opinions on the Visual Studio Code Analysis and Code Metrics forum (http://social.msdn.microsoft.com/Forums/en-US/vstscode/). To provide feedback directly to the development team, you can file a bug on the Connect site for Visual Studio 2010 and .NET Framework 4 (https://connect.microsoft.com/VisualStudio). The dev team encourages your feedback through these channels.
- 7/8/2010
- Medinoc
- 11/11/2010
- Patrick Sheahan
