Best practice: lancio di eccezioni dalle proprietà

Question

Quando è opportuno lanciare un'eccezione all'interno di un getter o setter di proprietà? Quando non è appropriato? Perché? I link a documenti esterni sull'argomento sarebbero utili ... Google si è rivelato sorprendentemente piccolo.

Answer 1

Microsoft ha le sue raccomandazioni su come progettare le proprietà a http://msdn.microsoft.com/en-us/library/ms229006.aspx

In sostanza, si consiglia di getter proprietà essere di accesso leggeri che sono sempre al sicuro chiamare. Raccomandano di ridisegnare i Getters come metodi se le eccezioni sono qualcosa che devi lanciare. Per i setter indicano che le eccezioni sono una strategia di gestione degli errori appropriata e accettabile.

Per gli indicizzatori, Microsoft indica che è accettabile che getter e setter generino eccezioni. E in effetti, molti indicizzatori nella libreria .NET lo fanno. L'eccezione più comune è ArgumentOutOfRangeException.

Ci sono alcune buone ragioni per le quali non si desidera generare eccezioni in getter di proprietà:

• Poiché le proprietà "sembrano" essere i campi, non è sempre evidente che essi possono gettare una (da -design) eccezione; mentre con i metodi, i programmatori sono addestrati ad aspettarsi e indagare se le eccezioni sono una conseguenza prevista di invocare il metodo.
• I getter sono utilizzati da molte infrastrutture .NET, come i serializzatori e il databinding (in WinForms e WPF per esempio) - occuparsi di eccezioni in tali contesti può rapidamente diventare problematico.
• I getter di proprietà vengono automaticamente valutati dai debugger quando si guarda o si ispeziona un oggetto. Un'eccezione qui può essere fonte di confusione e rallentare gli sforzi di debug. È inoltre indesiderabile eseguire altre costose operazioni nelle proprietà (come l'accesso a un database) per gli stessi motivi.
• Le proprietà sono spesso utilizzate in una convenzione di concatenazione: obj.PropA.AnotherProp.YetAnother - con questo tipo di sintassi diventa problematico decidere dove iniettare le dichiarazioni di cattura delle eccezioni.

Come nota a margine, si deve essere consapevoli che solo perché una proprietà viene non progettato un'eccezione, questo non significa che non; potrebbe facilmente chiamare il codice che lo fa. Anche il semplice atto di allocare un nuovo oggetto (come una stringa) potrebbe comportare delle eccezioni. Dovresti sempre scrivere il tuo codice in modo difensivo e aspettarti eccezioni da qualsiasi cosa tu invochi.

Answer 2

MSDN: Cattura e generazione di tipi di eccezioni standard

http://msdn.microsoft.com/en-us/library/ms229007.aspx

Answer 3

Non è quasi mai appropriato su un getter, e talvolta appropriato su un setter.

La migliore risorsa per questo tipo di domande è "Framework Design Guidelines" di Cwalina e Abrams; è disponibile come libro rilegato e grandi porzioni sono disponibili anche online.

Da paragrafo 5.2: dell'immobile in stile

evitare di gettare eccezioni getter proprietà. I getter di proprietà dovrebbero essere semplici operazioni e dovrebbero non avere precondizioni.Se un getter può lanciare un'eccezione, dovrebbe essere probabilmente ridisegnato per essere un metodo. Si noti che questa regola non si applica agli indicizzatori , dove ci si aspettano le eccezioni come risultato della convalida degli argomenti con gli argomenti .

Si noti che questa linea guida applica solo ai getter di proprietà. È OK gettare un'eccezione in un setter di proprietà.

Answer 4

Tutto questo è documentato in MSDN (come legata a in altre risposte), ma qui è una regola generale ...

Nel setter, se la vostra proprietà deve essere convalidato al di là tipo. Ad esempio, una proprietà denominata PhoneNumber dovrebbe probabilmente avere la convalida di espressioni regolari e dovrebbe generare un errore se il formato non è valido.

Per getter, probabilmente quando il valore è nullo, ma molto probabilmente è qualcosa che si desidera gestire sul codice chiamante (secondo le linee guida di progettazione).

Answer 5

Non c'è niente di sbagliato nel lanciare le eccezioni dai setter. Dopo tutto, quale modo migliore per indicare che il valore non è valido per una determinata proprietà?

Per i getter, è generalmente disapprovato e che può essere spiegato abbastanza facilmente: un getter di proprietà, in generale, segnala lo stato corrente di un oggetto; quindi, l'unico caso in cui è ragionevole che un getter lanci è quando lo stato non è valido. Ma generalmente è anche considerata una buona idea progettare le classi in modo tale che non sia possibile ottenere inizialmente un oggetto non valido, o metterlo in uno stato non valido con mezzi normali (cioè, assicurarsi sempre la completa inizializzazione nei costruttori, e prova a rendere i metodi eccezionalmente sicuri rispetto alla validità dello stato e agli invarianti di classe). Fintanto che continui a rispettare questa regola, i getter della tua proprietà non dovrebbero mai entrare in una situazione in cui devono segnalare uno stato non valido, e quindi non lanciare mai.

Esiste un'eccezione che conosco ed è in realtà piuttosto importante: qualsiasi oggetto che implementa IDisposable. Dispose è specificamente inteso come un modo per portare l'oggetto in uno stato non valido e c'è anche una classe di eccezione speciale, ObjectDisposedException, da utilizzare in quel caso. È perfettamente normale lanciare ObjectDisposedException da qualsiasi membro della classe, inclusi i getter di proprietà (escluso lo Dispose), dopo che l'oggetto è stato eliminato.

Answer 6

Un approccio bello eccezioni è quella di usarli per documentare il codice per te stesso e gli altri sviluppatori come segue:

eccezioni dovrebbero essere per gli Stati programma eccezionale. Ciò significa che è bello scriverli dove vuoi!

Una ragione per cui si potrebbe desiderare di inserirli nei getter è documentare l'API di una classe - se il software genera un'eccezione non appena un programmatore tenta di utilizzarla in modo errato, non lo userà in modo errato! Ad esempio, se hai una convalida durante un processo di lettura dei dati, potrebbe non avere senso poter continuare e accedere ai risultati del processo se ci sono errori fatali nei dati. In questo caso potresti voler ottenere il lancio dell'output se ci sono errori per assicurare che un altro programmatore controlli questa condizione.

Sono un modo di documentare le ipotesi e i limiti di un sottosistema/metodo/qualsiasi cosa. Nel caso generale non dovrebbero essere catturati!Questo è anche perché non vengono mai lanciati se il sistema sta lavorando insieme nel modo previsto: se si verifica un'eccezione mostra che le ipotesi di un pezzo di codice non sono soddisfatte - per esempio non sta interagendo con il mondo circostante nel modo in cui era originariamente destinato a. Se si rileva un'eccezione scritta per questo scopo, probabilmente significa che il sistema è entrato in uno stato imprevedibile/incoerente - questo potrebbe portare a un arresto anomalo o corruzione di dati o simili che è probabilmente molto più difficile da rilevare/eseguire il debug.

I messaggi di eccezione sono un modo molto approssimativo di segnalare errori: non possono essere raccolti in massa e contengono solo una stringa. Ciò li rende inadatti a segnalare problemi nei dati di input. Nel normale funzionamento il sistema stesso non dovrebbe entrare in uno stato di errore. Di conseguenza, i messaggi in essi contenuti dovrebbero essere progettati per i programmatori e non per gli utenti: le cose che non sono corrette nei dati di input possono essere scoperte e inoltrate agli utenti in formati (personalizzati) più appropriati.

L'eccezione (haha!) A questa regola è simile all'IO dove le eccezioni non sono sotto il tuo controllo e non possono essere controllate in anticipo.

Answer 7

Questa è una domanda molto complessa e la risposta dipende da come viene utilizzato l'oggetto. Come regola generale, i getter di proprietà e i setter che "legano in ritardo" non devono generare eccezioni, mentre le proprietà con "binding anticipato" esclusivo devono generare eccezioni in caso di necessità. A proposito, lo strumento di analisi del codice di Microsoft sta definendo l'uso delle proprietà troppo ristretto a mio parere.

"rilegatura tardiva" indica che le proprietà si trovano attraverso la riflessione. Ad esempio, l'attributo Serializzabile è usato per serializzare/deserializzare un oggetto tramite le sue proprietà. Lanciare un'eccezione durante questo tipo di situazioni rompe le cose in modo catastrofico e non è un buon modo di usare le eccezioni per creare un codice più robusto

"associazione anticipata" significa che un uso di proprietà è associato nel codice dal compilatore.Ad esempio, quando un codice che scrivi fa riferimento a un getter di proprietà.In questo caso è OK generare eccezioni quando hanno senso

Un oggetto con attributi interni ha uno stato determinato dai valori di tali attributi.Le proprietà che esprimono gli attributi che sono consapevoli e sensibili allo stato interno dell'oggetto non devono essere utilizzate per l'associazione tardiva. Ad esempio, supponiamo di avere un oggetto che deve essereaperto, accessibile, quindi chiuso. In questo caso, l'accesso alle proprietà senza chiamare prima aperto dovrebbe comportare un'eccezione. Supponiamo, in questo caso, di non generare un'eccezione e di consentire al codice di accedere a un valore senza generare un'eccezione? Il codice sembrerà felice anche se ha un valore da un getter che non ha senso. Ora abbiamo messo il codice che ha chiamato il getter in una brutta situazione dato che deve sapere come controllare il valore per vedere se non ha senso. Ciò significa che il codice deve fare ipotesi sul valore che ha ottenuto dal getter della proprietà per convalidarlo. Ecco come viene scritto il codice errato.

Answer 8

Avevo questo codice in cui non ero sicuro di quale eccezione lanciare.

public Person 
{ 
    public string Name { get; set; } 
    public boolean HasPets { get; set; } 
} 

public void Foo(Person person) 
{ 
    if (person.Name == null) { 
     throw new Exception("Name of person is null."); 
     // I was unsure of which exception to throw here. 
    } 

    Console.WriteLine("Name is: " + person.Name); 
} 

I impedito il modello di avere la proprietà di essere nullo in primo luogo forzando come argomento nel costruttore.

public Person 
{ 
    public Person(string name) 
    { 
     if (name == null) { 
      throw new ArgumentNullException(nameof(name)); 
     } 
     Name = name; 
    } 

    public string Name { get; private set; } 
    public boolean HasPets { get; set; } 
} 

public void Foo(Person person) 
{ 
    Console.WriteLine("Name is: " + person.Name); 
}