Nunit: Eliminando a classe Guard

Criado em 24 set. 2018 · 4Comentários · Fonte: nunit/nunit

ReSharper e (nos últimos anos) Visual Studio sugerem a inserção de ArgumentNullException e verificações de argumentos semelhantes. É tanta memória muscular que eu os introduzi por acidente na base de código várias vezes.

Lançar diretamente é C# mais idiomático do ponto de vista da análise de controle de fluxo. O compilador C# entende que você não precisa retornar um valor ou inicializar uma variável antes do uso ou interromper um switch case se você usar throw vez de Guard . A verificação de fluxo nulo do ReSharper é da mesma maneira.

Além disso, com o C# 7.0, as expressões de lançamento podem ser convenientes. Por exemplo, a sintaxe _foo = foo ?? throw new ArgumentNullException(nameof(Foo)); .

Quais são os outros prós ou contras de permitir que os contribuidores e nós mesmos lancemos exceções diretamente em vez de usar o Guard?

Fonte

jnm2

Comentários muito úteis

Eu pessoalmente gosto da classe de guarda - mas concordo que há um problema de descoberta. Eu normalmente sugeriria isso para contribuidores regulares, mas não o mencionaria para contribuidores pontuais. Eu não acho que esta é uma área que nós particularmente precisamos de consistência, não é? Fico feliz em vê-lo quando está lá, mas não me preocupo quando não está.

Estou bastante apático com o resultado deste problema, de qualquer forma está bom para mim 😊

ChrisMaddock em 24 set. 2018

👍3

Todos 4 comentários

A principal vantagem de usar a classe Guard é a facilidade de uso, se estou lembrando corretamente. Em um IDE compatível com C#, não é mais a opção mais fácil para mim ou para novos colaboradores. Precisamos de consistência, tudo de um jeito ou de outro jeito? A consistência coloca o que é mais fácil para alguns de nós contra (potencialmente) o que é mais fácil para outros de nós.

jnm2 em 24 set. 2018

Estou bastante apático com o resultado deste problema, de qualquer forma está bom para mim 😊

ChrisMaddock em 24 set. 2018

👍3

Eu também sou um pouco apático sobre isso. Ele fornece consistência e uso correto de construtores de exceção (já vi a mensagem e o nome do parâmetro de trás para frente algumas vezes), mas também adiciona um método extra à pilha de chamadas. Além disso, como você disse, a nova sintaxe do C# facilita muito.

Não tenho certeza se precisamos de um expurgo por atacado, mas estou bem em não exigir.