Leggere in inglese

Condividi tramite

CA1065: Non generare eccezioni in posizioni non previste

  • Articolo
Proprietà valore
ID regola CA1065
Title Non generare eccezioni in posizioni non previste
Categoria Progettazione
La correzione causa un'interruzione o meno Non causa un'interruzione
Abilitato per impostazione predefinita in .NET 9 No

Causa

Un metodo che normalmente non genera eccezioni genera un'eccezione.

Descrizione regola

I metodi che non devono generare eccezioni possono essere classificati come segue:

  • Metodi get della proprietà
  • Metodi della funzione di accesso agli eventi
  • Metodi Equals
  • Metodi GetHashCode
  • Metodi ToString
  • Costruttori statici
  • Finalizzatori
  • Metodi Dispose
  • Operatori di uguaglianza
  • Operatori cast impliciti

Le sezioni seguenti illustrano questi tipi di metodo.

Metodi get della proprietà

Le proprietà sono fondamentalmente campi intelligenti. Pertanto, dovrebbero comportarsi come un campo il più possibile. I campi non generano eccezioni e non devono essere proprietà. Se si dispone di una proprietà che genera un'eccezione, è consigliabile crearla come metodo.

È possibile generare le eccezioni seguenti da un metodo get di proprietà:

Metodi della funzione di accesso agli eventi

Le funzioni di accesso agli eventi devono essere semplici operazioni che non generano eccezioni. Un evento non deve generare un'eccezione quando si tenta di aggiungere o rimuovere un gestore eventi.

È possibile generare le eccezioni seguenti da una funzione di accesso agli eventi:

Metodi Equals

I metodi Equals seguenti non devono generare eccezioni:

Un Equals metodo deve restituire true o false anziché generare un'eccezione. Ad esempio, se Equals vengono passati due tipi non corrispondenti, deve essere restituito false semplicemente anziché generare un oggetto ArgumentException.

Metodi GetHashCode

I metodi seguenti GetHashCode in genere non generano eccezioni:

GetHashCode deve restituire sempre un valore. In caso contrario, è possibile perdere elementi nella tabella hash.

Le versioni di GetHashCode che accettano un argomento possono generare un'eccezione ArgumentException. Tuttavia, Object.GetHashCode non dovrebbe mai generare un'eccezione.

Metodi ToString

Il debugger usa System.Object.ToString per visualizzare informazioni sugli oggetti in formato stringa. Pertanto, ToString non deve modificare lo stato di un oggetto e non deve generare eccezioni.

Costruttori statici

La generazione di eccezioni da un costruttore statico causa l'inutilizzabilità del tipo nel dominio applicazione corrente. È necessario avere un buon motivo (ad esempio un problema di sicurezza) per generare un'eccezione da un costruttore statico.

Finalizzatori

La generazione di un'eccezione da un finalizzatore causa un errore rapido di CLR, che rimuove il processo. Pertanto, evitare di generare eccezioni in un finalizzatore.

Metodi Dispose

Un System.IDisposable.Dispose metodo non deve generare un'eccezione. Dispose viene spesso chiamato come parte della logica di pulizia in una finally clausola . Pertanto, generando in modo esplicito un'eccezione da Dispose forza l'utente ad aggiungere la gestione delle eccezioni all'interno della finally clausola .

Il percorso del Dispose(false) codice non deve mai generare eccezioni, perché Dispose viene quasi sempre chiamato da un finalizzatore.

Operatori di uguaglianza (==, !=)

Analogamente Equals ai metodi, gli operatori di uguaglianza devono restituire true o falsee non devono generare eccezioni.

Operatori cast impliciti

Poiché l'utente spesso non è a conoscenza del fatto che è stato chiamato un operatore cast implicito, un'eccezione generata dall'operatore cast implicito è imprevista. Di conseguenza, non devono essere generate eccezioni da operatori cast impliciti.

Come correggere le violazioni

Per i getter delle proprietà, modificare la logica in modo che non sia più necessario generare un'eccezione o modificare la proprietà in un metodo.

Per tutti gli altri tipi di metodo elencati in precedenza, modificare la logica in modo che non debba più generare un'eccezione.

Quando eliminare gli avvisi

Se la violazione è stata causata da una dichiarazione di eccezione anziché da un'eccezione generata, è possibile eliminare un avviso da questa regola.

Eliminare un avviso

Se si vuole eliminare una singola violazione, aggiungere direttive del preprocessore al file di origine per disabilitare e quindi riabilitare la regola.

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

Per disabilitare la regola per un file, una cartella o un progetto, impostarne la gravità none su nel file di configurazione.

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

Per altre informazioni, vedere Come eliminare gli avvisi di analisi del codice.

Vedi anche