Uso de NotImplementedException

É uma prática recomendada jogar NotImplementedExceptioncódigo que você ainda não escreveu? Possivelmente os comentários do TODO seriam considerados mais seguros?

Eu acredito que NotImplementedExceptioné realmente uma boa prática.

De fato, se você esquecer de implementar um método e usá-lo mais tarde em seu projeto (e acredite, isso acontece), você poderá passar um longo tempo depurando procurando o que deu errado passo a passo. Se você tiver a exceção, o programa será interrompido diretamente, solicitando a exceção (se você capturar a exceção, você a encontrará rapidamente, observando a exceção que capturou).

Eu recomendaria usar os comentários NotImplementedException combinados com os TODO, para combinar a ajuda da GUI (com as tarefas no VS) e a segurança do programa.

Para a versão de lançamento, é ainda mais importante na minha opinião, pois na maioria dos casos você prefere que seu programa trave ao invés de ter um programa aparentemente funcionando corretamente, mas produzindo resultados errôneos.

Depende da sua filosofia geral sobre erros e manipulação de erros. Eu sou o tipo de cara com "erro grave": lançarei uma exceção ao menor sinal de que algo pode estar errado; Vou afirmar tudo; Se houver um erro, se algo deveria estar lá, e não está, ou se algo está lá, e não deveria, todo o universo deve parar. O som de exclamação das janelas deve soar ameaçadoramente pelos alto-falantes.

Há outras pessoas que preferem não se incomodar com erros. E se o enviarmos para o cliente e todo o módulo de relatórios estiver ausente, porque esquecemos de codificá-lo e ninguém nos testes percebeu isso, porque o aplicativo ficou muito silencioso sobre isso? Melhor não fazer nada, do que lançar uma exceção na cara do cliente!

Eu diria que é uma boa ideia. Normalmente, vejo essas exceções geradas pelo código de esqueleto gerado automaticamente a partir de um formulário, diagrama ou algo assim. A exceção me lembra a implementação do código e garante que haverá erros se eu tentar usar a funcionalidade que foi configurada, mas nunca totalmente implementada. Às vezes, eu o removo ou substituo por algo com menor probabilidade de interromper a execução (como imprimir um aviso no console), mas acho que funciona para mim.

Se você estiver criando uma biblioteca que outras pessoas usarão, ter essa exceção é melhor que a alternativa, que seria um usuário da sua biblioteca chamando uma função e se perguntando por que nada parecia acontecer. Obviamente, ainda é muito ruim ter essa exceção em uma biblioteca fornecida, mas é melhor do que falhas silenciosas, IMO.

Eu acho que é uma boa prática. A alternativa é propagar um valor ou estado inválido, o que afetará o código de teste e de produção.

Eu sempre uso NotImplementedException- é para isso, afinal.

Isso está relacionado ao conceito de "falha rápida": se seu código está lançando uma exceção, isso deve ser detectado antes de ir para a produção. Se chegar à produção, pelo menos o cliente saberá que a montagem está incorreta .

Se o código retornar um valor sem sentido ou, para os voidmétodos, não executar nenhuma ação, os consumidores do seu código poderão pensar razoavelmente que a chamada era significativa quando não era. Posteriormente, quando eles obtiverem o código correto, o código poderá ser quebrado porque depende do antigo comportamento incorreto.

Que tipo de projeto é esse? Trabalho ou casa? Em casa, faça o que quiser - o que melhor lhe lembra que você precisa terminar o que quer que esteja trabalhando.

No trabalho, termine de escrever.

Não consigo ver uma situação em que eu verificaria o código que pode / irá quebrar outros desenvolvedores, controle de qualidade ou uma compilação.

Faço as duas coisas, mas a \ todo, na auto-identificação do doxygene e, em seguida, lanço a exceção. Dessa forma, se as pessoas não puderem se incomodar com o RTFM, pelo menos, serão capazes de descobrir por que seu programa travou, em vez de se perguntar por que há uma função declarada que não está retornando um valor lógico.