Requerendo Manipulação de Referência Nula Explícita

Question

Requerendo Manipulação de Referência Nula Explícita

#1 resposta do (4 votos)
#2 resposta do (3 votos)

5

Um dos problemas que tenho com referências nulas é que eles podem não ser excepcionais. Na minha posição atual, há poucos requisitos e você tem sorte se as convenções forem seguidas. Isso significa que ser incapaz de lidar com uma solicitação é uma ocorrência freqüente e lançar uma exceção é muito lento (pense em milhões de solicitações). Eu sou responsável por escrever uma API para lidar com essas solicitações e estou tentando decidir como lidar com falhas.

Nosso código está escrito em C # e eu sou um grande fã do LINQ. Eu sei que LINQ lida com esse problema, fornecendo dois métodos "Function ()" e "FunctionOrDefault ()". Ao retornar o valor padrão (geralmente nulo), tornamos muito fácil para o desenvolvedor dar um tiro no próprio pé. Por outro lado, lançar uma exceção é inaceitável para nós. Há também o padrão "TryParse", mas isso não se presta bem a expressões lambda.

Eu descobri recentemente o tipo de opção em F # e como ele requer o tratamento explícito de alguns e nenhum caso ou seu assembly não será compilado. Isso parece ser uma solução muito melhor para o problema do valor nulo do que deixar para o desenvolvedor lembrar de implementar o tratamento de erros.

Eu poderia implementar um tipo de opção que não compilará e retornará o valor desejado, a menos que os casos Some e Nenhum sejam tratados. O contrato para minha implementação ficaria assim:

Option<SomeClass> option = new SomeClass { Value = 5 }.ToOption(); // Extension method
int value = option.Some(x => x.Value).None(x => x.Default(25)); // Other helper methods provided as well for None cases.

Então, minha pergunta é: se eu tiver a capacidade de exigir tratamento de referência nula explícito, há desvantagens nessa abordagem? Seria melhor manter as convenções do que tentar resolver esse problema antecipadamente para evitar futuros bugs ocultos?

c# api null

por mortalapeman 23.03.2013 / 05:37

fonte

2 respostas

3

By returning the default value (usually null), we make it very easy for the developer to shoot himself in the foot.

Eu não concordo, e acho que você está no caminho da engenharia excessiva. Se você tiver uma função retornando null e o usuário dessa função manipular corretamente, tudo estará bem. Se o usuário não (o que significa que ele tenta usar o objeto retornado), ele receberá uma exceção, então nenhum erro será mascarado .

O único problema aqui é que o usuário pode não receber uma mensagem de erro clara. Mas esse também seria o caso quando você usa qualquer outro tipo de mecanismo de sinalização de erro e o usuário de suas funções se esquece de "traduzir" mensagens de erro técnicas para mensagens de texto não criptografado que mostram a causa raiz de um problema.

Invista melhor o tempo para ensinar seus companheiros de equipe a escrever testes para revelar o tratamento de erros ausente.

por 23.03.2013 / 11:51

fonte

Tags c# api null

Testar o desenvolvimento orientado ao implementar uma lista de comprimento flexível Banco de dados de documentos NoSQL como uma fila de mensagens

score 4 · Accepted Answer

Você não precisa disso. Aqui está o meu raciocínio:

Você pode estar subestimando os consumidores da sua API. Cada livro que eu li em linguagens de programação continha uma seção sobre como verificar valores nulos. Muitos idiomas incluem coalescência nula ou recursos de verificação de nulos + açúcar sintático.
Você precisa provar para mim (outro programador) por que você precisa desta convenção . Se você não puder provar que ele fornece um fluxo de trabalho significativo ou um benefício de depuração, será necessário usar uma abordagem mais simples. Especialmente se a abordagem mais simples já é ensinada pela comunidade em geral.
```
var value = proxy.FirstOrDefault();
if (value != null) { ...
```
Considere o significado das expressões idiomáticas que você cria. O código está acima ou abaixo do seu método ToOption() ? Se eles são quase o mesmo, não faça isso. Apenas faça um trabalho que forneça um benefício significativo. Esta é a ideia básica por trás do YAGNI.
Considere um debate semelhante na comunidade do NAME sobre a utilidade de aplicar o padrão Promise / A para bibliotecas. Embora não seja equivalente, você pode ver que há alguma descontinuidade no problema.
Por fim, gostaria de deixar de lado o fato de permitir que seus consumidores escolham o nível de complexidade que desejam. Se a sua abordagem ToOption for claramente superior, os consumidores a implementarão de qualquer maneira.