Utilizzo di NotImplementedException

È considerata una cattiva pratica lanciare NotImplementedExceptionper il codice che non hai ancora scritto? Forse i commenti TODO sarebbero considerati più sicuri?

Credo che in NotImplementedExceptionrealtà sia una buona pratica.

In effetti, se dimentichi di implementare un metodo e lo usi in seguito nel tuo progetto (e credimi, succede), potresti dedicare molto tempo al debug alla ricerca di ciò che è andato storto passo dopo passo. Se si dispone dell'eccezione, il programma si arresterà direttamente, richiedendo l'eccezione (se si rileva l'eccezione, la si troverà rapidamente cercando quale eccezione si è rilevata).

Vorrei raccomandare l'uso dei commenti NotImplementedException combinati con TODO, in questo modo si combina l'aiuto della GUI (con i compiti in VS) e la sicurezza del programma.

Per la versione di rilascio, è ancora più importante secondo me, poiché nella maggior parte dei casi preferiresti che il tuo programma andasse in crash piuttosto che avere un programma che apparentemente funzionasse correttamente ma producesse risultati errati.

Dipende dalla tua filosofia generale su errori e gestione degli errori. Sono il tipo di "errore duro" di tipo: lancerò un'eccezione al minimo accenno che qualcosa potrebbe essere sbagliato; Affermerò tutto; Se c'è un errore, se ci si aspettava che ci fosse qualcosa, e non lo è, o se c'è qualcosa, e non dovrebbe, l'intero universo deve fermarsi. Il suono esclamativo di Windows deve squillare minacciosamente attraverso gli altoparlanti.

Ci sono altre persone che preferiscono non essere disturbate da errori. Quindi cosa succede se lo spediamo al client e manca l'intero modulo dei rapporti perché ci siamo dimenticati di codificarlo, e nessuno nei test lo ha realizzato, perché l'applicazione era fin troppo silenziosa? Meglio non fare nulla, che lanciare un'eccezione in faccia al cliente!

Direi che è una buona idea. Di solito vedo quelle eccezioni generate dal codice scheletro che viene generato automaticamente da una forma o diagramma o qualcosa del genere. L'eccezione mi ricorda di implementare il codice e si assicura che ci siano errori se provo ad usare la funzionalità che è stata impostata ma mai completamente implementata. A volte lo interrompo o lo sostituisco con qualcosa che ha meno probabilità di interrompere l'esecuzione (come stampare un avviso sulla console), ma trovo che funzioni per me.

Se stai costruendo una libreria che altri useranno con questa eccezione è meglio dell'alternativa, che sarebbe un utente della tua libreria che chiama una funzione e si chiede perché non sembra accadere nulla. Certo, è ancora abbastanza male avere questa eccezione in una libreria spedita, ma meglio di guasti silenziosi, IMO.

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

Uso sempre NotImplementedException- questo è quello che serve, dopo tutto.

Questo è legato al concetto di "fail fast": se il tuo codice genera un'eccezione, questo dovrebbe essere catturato prima di passare alla produzione. Se arriva alla produzione, almeno il client sa che l'assembly non è corretto .

Se il codice restituisce un valore insignificante o, per i voidmetodi, non interviene, gli utenti del codice potrebbero ragionevolmente pensare che la chiamata fosse significativa quando non lo era. Successivamente, quando ottengono un 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, qualunque cosa ti ricordi che devi finire qualunque cosa tu stia lavorando.

Al lavoro, finisci di scriverlo.

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

Faccio sia io che un \ todo nel mio doxygene autodocing e quindi 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.