CA1065: Non generare eccezioni in posizioni non previste
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 8 | 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à:
- System.InvalidOperationException e tutti i derivati (incluso System.ObjectDisposedException)
- System.NotSupportedException e tutti i derivati
- System.ArgumentException (solo da get indicizzato)
- System.Collections.Generic.KeyNotFoundException (solo da get indicizzato)
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:
- System.InvalidOperationException e tutti i derivati (incluso System.ObjectDisposedException)
- System.NotSupportedException e tutti i derivati
- System.ArgumentException derivati e
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 false
e 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.
#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.
[*.{cs,vb}]
dotnet_diagnostic.CA1065.severity = none
Per altre informazioni, vedere Come eliminare gli avvisi di analisi del codice.