Devo attivare il controllo in fase di esecuzione dei contratti di codice per .NET 4.0 sui build di rilascio?

Question

Supponendo che tutto il nuovo codice di .NET 4.0

Vedo che c'è la possibilità di accenderli. Tuttavia, non vedo quale sia la migliore pratica?

È la procedura migliore che una volta eseguito il controllo statico, non è necessario eseguire il controllo in fase di esecuzione (poiché il compilatore si assicura che le condizioni siano soddisfatte)? O ci sono degli scenari in cui anche se il compilatore lo controlla per te, è ancora possibile che durante il runtime la condizione non venga soddisfatta?

Qualsiasi buona discussione o articolo online su questo. Ne vedo molti che spiegano come fare o meno, ma non molti che spiegano quale sia la migliore pratica assumendo tutto il nuovo codice .NET 4.0 senza la compatibilità con le versioni precedenti.

Answer 1

poiché il compilatore si assicura che le condizioni siano soddisfatte?

Sarà molto raro che il verificatore statica sarà in grado di verificare l'intera applicazione. Normalmente ci accontenteremo delle parti principali.

Devo attivare il controllo in fase di esecuzione dei contratti di codice per .NET 4.0 sui build di rilascio?

Probabilmente non è il opzione Full, ma uno di quelli più leggeri come precondizioni Solo.

Per codice critico delle prestazioni, è possibile che si desideri disattivarli completamente.

Answer 2

Dipende dal modo in cui si utilizza Richiede.

Se si utilizza 'Custom contratto richiede' modalità:

public void SomeMethod(SomeClass x) 
{ 
    if (x == null) throw new ArgumentNullException("x"); 
    Contract.EndContractBlock(); 

    ... 
} 

si può tranquillamente girare run-time controlla off, e mantenere i vostri controlli di errore e le eccezioni

Se si utilizza 'contratto standard richiede' modalità:

public void SomeMethod(SomeClass x) 
{ 
    Contract.Requires<ArgumentNullException>(x != null); 

    ... 
} 

si dovrebbe trasformare i controlli di runtime almeno al livello 'ReleaseRequires'. In caso contrario, perderai tutti i controlli di errore e potresti ottenere eccezioni impreviste (ad esempio NullReferenceException in qualche punto nel codice anziché

Non userò i più alti livelli di controllo per un motivo molto semplice: se c'è ne contratto diverso da Contract.Requires<E> non riesce, il runtime genererà un System.Diagnostics.ContractException che probabilmente non piacerà agli utenti.

BTW, Henk Holterman ha assolutamente ragione che il verificatore statico è limitato e non si deve fare affidamento su di esso completamente.