Uso di NotImplementedException

Credo che NotImplementedException sia effettivamente una buona pratica.

In effetti, se ti dimentichi di implementare un metodo e lo utilizzi più avanti nel tuo progetto (e credimi, succede), potresti passare molto tempo a fare il debug cercando quello che è andato storto, passo dopo passo. Se hai un'eccezione, il programma si fermerà direttamente, chiedendo l'eccezione (se rilevi l'eccezione, lo troverai rapidamente osservando quale eccezione hai catturato).

Consiglierei di utilizzare NotImplementedException combinato con i commenti di TODO, in questo modo combinerete la guida della GUI (con le attività in VS) e la sicurezza del programma.

Per la versione di rilascio, è ancora più importante secondo me, poiché nella maggior parte dei casi preferiresti il tuo programma in crash piuttosto che avere un programma che funziona in modo apparente ma che produce risultati errati.

Dipende dalla tua filosofia generale riguardo agli errori e alla gestione degli errori. Io sono il tipo di "errore duro": farò un'eccezione al minimo indizio che qualcosa potrebbe essere sbagliato; Affermo tutto; Se c'è un errore, se ci si aspetta che ci sia qualcosa, e non lo è, o se c'è qualcosa, e non dovrebbe, l'intero universo deve fermarsi. Il suono esclamativo di Windows deve suonare minacciosamente attraverso gli altoparlanti.

Ci sono altre persone che preferirebbero non essere disturbate da errori. Quindi, se lo spediamo al client e manca l'intero modulo dei report perché ci siamo dimenticati di codificarlo, e nessuno in fase di testing l'ha realizzato, perché l'applicazione era troppo silenziosa al riguardo? Meglio non fare nulla, piuttosto che lanciare un'eccezione sul volto del cliente!

Direi che è una buona idea. Di solito vedo quelle eccezioni generate da un codice skeleton che viene generato automaticamente da una forma o da un diagramma o qualcosa del genere. L'eccezione mi ricorda di implementare il codice e mi assicura che ci saranno degli errori se cerco di utilizzare la funzionalità che è stata impostata, ma mai completamente implementata. A volte lo spegno o lo sostituisco con qualcosa che è meno probabile che interrompa l'esecuzione (come la stampa di un avviso alla console), ma trovo che funzioni per me.

Se stai costruendo una libreria che altri useranno usando questa eccezione è meglio dell'alternativa, che sarebbe un utente della tua libreria che chiama una funzione e si chiede perché non è successo niente. Ovviamente, è ancora piuttosto brutto avere questa eccezione in una libreria spedita, ma meglio degli errori silenziosi, IMO.

Penso che sia una buona pratica. L'alternativa sta propagando un valore o uno stato non valido, che influenzerà sia il codice di test che quello di produzione.

Uso sempre NotImplementedException - questo è quello che è, dopotutto.

Questo è legato al concetto di "fail fast": se il tuo codice lancia un'eccezione, questo dovrebbe essere scoperto prima di andare in produzione. Se arriva alla produzione, almeno il client sa che l'assembly è errato .

Se il codice restituisce un valore privo di significato o, per i metodi void , non intraprende alcuna azione, i consumatori del codice potrebbero ragionevolmente pensare che la chiamata fosse significativa quando non lo era. Successivamente, quando riceveranno del codice corretto, il loro codice potrebbe interrompersi perché dipende dal precedente comportamento errato.

Che tipo di progetto è questo? Lavoro o casa? A casa, fai quello che vuoi - qualsiasi cosa ti ricordi meglio che hai bisogno di finire qualunque cosa tu stia lavorando.

Al lavoro, finisci di scriverlo.

Non riesco a vedere una situazione in cui eseguirò il check-in del codice che può / interromperà altri sviluppatori, QA o una build.

Faccio entrambe le cose, ma a \ todo nel mio doxygene autodocing e poi lancio l'eccezione. In questo modo, se le persone non possono essere disturbate da RTFM almeno saranno in grado di capire perché il loro programma si è bloccato, invece di chiedersi perché esiste una funzione dichiarata che non restituisce un valore logico.