Devo creare la mia classe Assert in base a questi motivi?

3

Il motivo principale per cui Debug.Assert non mi piace è il fatto che queste affermazioni sono disabilitate in Release. So che c'è una ragione per le prestazioni, ma almeno nella mia situazione credo che i guadagni supererebbero il costo. (A proposito, immagino che questa sia la situazione nella maggior parte dei casi). E sì, so che puoi usare Trace.Assert invece. Ma anche se funzionasse, trovo il nome Trace che distrae, dal momento che non lo vedo come traccia.

L'altra ragione per creare la mia classe è la pigrizia, suppongo, dato che potrei scrivere metodi per i casi più comuni come Assert.IsNotNull, Assert.Equals e così via.

La seconda parte della mia domanda riguarda l'uso di Environment.FailFast in questa classe. Sarebbe una buona idea? Mi piacciono le idee presentate in questo documento . È praticamente da dove ho avuto l'idea.

Un ultimo punto. Creare un design come questo implica avere un percorso di codice non testabile, come descritto in questa risposta di Eric Lippert su un altro (ma relativo) domanda?

    
posta Mike 19.03.2012 - 15:47
fonte

3 risposte

1

Sì, crea il tuo Assert se soddisfa i tuoi requisiti

Alcune aziende non hanno build 'release' - la singola build che usano ha le ottimizzazioni del compilatore disabilitate, i macro ASSERT-like ancora in funzione e una tonnellata di logging. Essere in grado di abilitare / configurare in modo dinamico il comportamento di ASSER al runtime è utile qui. Si desidera un comportamento simile a ASSERT in quanto se qualcosa non supera un test, fare qualcosa al riguardo piuttosto che lasciare che il programma continui ma essere in grado di commutare abort, logging, timing, raccolta delle statistiche e comportamento di throw-an-exception in fase di runtime è estremamente utile, specialmente se si hanno applicazioni server di grandi dimensioni con molti client e che possono avere tempi di attività prolungati.

System.Diagnostics.Assertisce il comportamento di abort e System.Diagostics.Trace esegue il logging, ma potrebbe essere adatto ai tuoi scopi per avere una combinazione di questi che era configurabile tramite .config o Registry Sign e ti ha dato l'accesso a qualunque è necessario assicurarsi che la qualità del software soddisfi le proprie esigenze.

Non posso prevedere cosa ti sarebbe utile, ma come punto di partenza:

  • È un errore condizionale in errore, un avvertimento o traccia.
  • Se il codice interrompe, genera, registra, invia per email o invia SMS il problema.
  • Indica se mantenere le statistiche sugli articoli sopra.
  • Indica se consentire la configurazione live di tutti questi elementi (utile per i processi del server).
risposta data 19.03.2012 - 17:57
fonte
6

The main reason I don't like Debug.Assert is the fact that these assertions are disabled in Release

Quello che stai cercando sono Contratti di codice ; una libreria di Microsoft che consente di formulare asserzioni che non devono essere violate (IE, argomenti nulli o una variabile del conto bancario inferiore a zero poco prima di un calcolo di interesse).

Offrono diversi modi per esprimere i tuoi vincoli e un controllore statico per avvertirti delle insidie nella tua base di codice senza mai eseguire alcun codice.

Cerca in "Design by contract" per informazioni non.NET su questo.

    
risposta data 19.03.2012 - 16:04
fonte
1

Se Trace ha tutte le funzionalità di cui hai bisogno e non puoi davvero scoprire il nome "Trace", puoi ereditarlo solo per mascherare il nome?

    
risposta data 19.03.2012 - 15:59
fonte

Leggi altre domande sui tag