RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1065 below:

CA1065: Do not raise exceptions in unexpected locations (code analysis) - .NET

Property Value Rule ID CA1065 Title Do not raise exceptions in unexpected locations Category Design Fix is breaking or non-breaking Non-breaking Enabled by default in .NET 9 No Cause

A method that is not expected to throw exceptions throws an exception.

Rule description

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 don't throw exceptions and neither should properties. If you have a property that throws an exception, consider making it a method.

The following exceptions can 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)
System.Collections.Generic.KeyNotFoundException (only from indexed get)

Event accessor methods

Event accessors should be simple operations that don't throw exceptions. An event should not throw an exception when you try to add or remove an event handler.

The following exceptions can be thrown from an event accessor:

System.InvalidOperationException and all derivatives (including System.ObjectDisposedException)
System.NotSupportedException and all derivatives
System.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 System.Object.ToString to help display information about objects in string format. Therefore, ToString should not change the state of an object, and it shouldn't 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 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, avoid throwing exceptions in a finalizer.

Dispose methods

A System.IDisposable.Dispose method should not throw an exception. Dispose is often called as part of the cleanup 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 Dispose 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 unexpected. Therefore, no exceptions should be thrown from implicit cast operators.

How to fix violations

For property getters, either change the logic so that it no longer has to throw an exception, or change the property into a method.

For all other method types listed previously, change the logic so that it no longer must throw an exception.

When to suppress warnings

If the violation was caused by an exception declaration instead of a thrown exception, it is safe to suppress a warning from this rule.

Suppress a warning

If you just want to suppress a single violation, add preprocessor directives to your source file to disable and then re-enable the rule.

#pragma warning disable CA1065
// The code that's violating the rule is on this line.
#pragma warning restore CA1065

To disable the rule for a file, folder, or project, set its severity to none in the configuration file.

[*.{cs,vb}]
dotnet_diagnostic.CA1065.severity = none

For more information, see How to suppress code analysis warnings.

CA2219: Do not raise exceptions in exception clauses