Devo aceitar coleções vazias em meus métodos que iteram sobre elas?

Eu tenho um método em que toda a lógica é realizada dentro de um loop foreach que itera sobre o parâmetro do método:

public IEnumerable<TransformedNode> TransformNodes(IEnumerable<Node> nodes)
{
    foreach(var node in nodes)
    {
        // yadda yadda yadda
        yield return transformedNode;
    }
}

Nesse caso, o envio de uma coleção vazia resulta em uma coleção vazia, mas estou me perguntando se isso é imprudente.

Minha lógica aqui é que, se alguém está chamando esse método, eles pretendem passar dados e só passariam uma coleção vazia para o meu método em circunstâncias errôneas.

Devo capturar esse comportamento e lançar uma exceção para ele, ou é uma prática recomendada retornar a coleção vazia?

Os métodos utilitários não devem ser lançados em coleções vazias. Seus clientes da API o odiariam por isso.

Uma coleção pode estar vazia; uma "coleção que não deve ser vazia" é conceitualmente uma coisa muito mais difícil de se trabalhar.

Transformar uma coleção vazia tem um resultado óbvio: a coleção vazia. (Você pode até economizar algum lixo retornando o próprio parâmetro.)

Existem muitas circunstâncias em que um módulo mantém listas de itens que podem ou não estar preenchidos com algo. Ter que verificar o vazio antes de cada chamada transformé irritante e tem o potencial de transformar um algoritmo simples e elegante em uma bagunça feia.

Os métodos de utilidade devem sempre se esforçar para serem liberais em suas entradas e conservadores em suas saídas.

Por todas essas razões, pelo amor de Deus, lide com a coleção vazia corretamente. Nada é mais irritante do que um módulo auxiliar que pensa que sabe o que você quer melhor do que você.

Vejo duas perguntas importantes que determinam a resposta para isso:

1. Sua função pode retornar algo significativo e lógico quando transmitida uma coleção vazia (incluindo nula )?
2. Qual é o estilo geral de programação neste aplicativo / biblioteca / equipe? (Especificamente, como você está no FP?)

1. Retorno significativo

Essencialmente, se você puder retornar algo significativo, não lance uma exceção. Deixe o chamador lidar com o resultado. Então, se sua função ...

• Conta o número de elementos na coleção, retorna 0. Isso foi fácil.
• Procura por elementos que correspondem a critérios específicos, retornando uma coleção vazia. Por favor, não jogue nada. O chamador pode ter uma enorme coleção de coleções, algumas vazias, outras não. O chamador deseja qualquer elemento correspondente em qualquer coleção. Exceções apenas tornam a vida do interlocutor mais difícil.
• Está procurando o maior / menor / melhor ajuste aos critérios da lista. Opa Dependendo da questão do estilo, você pode lançar uma exceção aqui ou retornar nulo . Eu odeio nulo (muito uma pessoa FP), mas é sem dúvida mais significativo aqui e permite reservar exceções para erros inesperados dentro do seu próprio código. Se o chamador não procurar nulo, uma exceção bastante clara resultará de qualquer maneira. Mas você deixa isso para eles.
• Solicita o enésimo item na coleção ou o primeiro / último n itens. Este é o melhor caso para uma exceção até agora e a que tem menor probabilidade de causar confusão e dificuldade para o chamador. Um caso ainda pode ser nulo se você e sua equipe estiverem acostumados a verificar isso, por todos os motivos mencionados no ponto anterior, mas esse é o caso mais válido ainda para lançar uma exceção DudeYou Know YouShouldCheckTheSizeFirst . Se o seu estilo é mais funcional, nulo ou leia a minha resposta de estilo .

Em geral, meu viés de FP me diz "retornar algo significativo" e nulo pode ter um significado válido nesse caso.

2. Estilo

Seu código geral (ou o código do projeto ou da equipe) favorece um estilo funcional? Se não, serão esperadas e tratadas exceções. Se sim, considere retornar um tipo de opção . Com um tipo de opção, você retorna uma resposta significativa ou Nada / Nada . No meu terceiro exemplo acima, Nothing seria uma boa resposta no estilo FP. O fato de a função retornar um tipo de opção sinalizar claramente para o chamador do que uma resposta significativa pode não ser possível e que o chamador deve estar preparado para lidar com isso. Eu sinto que isso dá ao chamador mais opções (se você perdoar o trocadilho).

F # é onde todas as frias .Net crianças fazem este tipo de coisa, mas C # faz apoiar este modelo.

tl; dr

Mantenha exceções para erros inesperados no seu próprio caminho de código, não totalmente previsível (e legal) de entrada de outra pessoa.

Como sempre, depende.

Será que importa que a coleção está vazia?
A maioria dos códigos de manipulação de coleções provavelmente diria "não"; uma coleção pode ter qualquer número de itens, incluindo zero.

Agora, se você tem algum tipo de coleção em que é "inválido" não ter itens, é um novo requisito e você precisa decidir o que fazer.

Peça emprestada alguma lógica de teste do mundo do banco de dados: teste para zero itens, um e dois itens. Isso atende aos casos mais importantes (eliminando quaisquer condições de junção internas ou cartesianas mal formadas).

Por uma questão de bom design, aceite o máximo possível de variações em suas entradas. Exceções só devem ser lançadas quando (entrada inaceitável é apresentada OU erros inesperados ocorrem durante o processamento) E o programa não pode continuar de maneira previsível como resultado.

Nesse caso, deve-se esperar que uma coleção vazia seja apresentada e seu código precise manipulá-la (o que já faz). Seria uma violação de tudo o que é bom se o seu código lançar uma exceção aqui. Isso seria semelhante à multiplicação de 0 por 0 em matemática. É redundante, mas absolutamente necessário para funcionar da maneira que funciona.

Agora, vamos ao argumento de coleção nula. Nesse caso, uma coleção nula é um erro de programação: o programador esqueceu de atribuir uma variável. Este é um caso em que uma exceção pode ser lançada, porque você não pode processá-la significativamente em uma saída, e tentar fazer isso introduziria um comportamento inesperado. Isso seria semelhante a dividir por zero em matemática - é completamente sem sentido.

A solução certa é muito mais difícil de ver quando você está apenas olhando para sua função isoladamente. Considere sua função como parte de um problema maior . Uma solução possível para esse exemplo é semelhante a esta (em Scala):

input.split("\\D")
.filterNot (_.isEmpty)
.map (_.toInt)
.filter (x => x >= 1000 && x <= 9999)

Primeiro, você divide a string por não dígitos, filtra as strings vazias, converte as strings em números inteiros e depois filtra para manter apenas os números de quatro dígitos. Sua função pode estar map (_.toInt)no pipeline.

Esse código é bastante simples, porque cada estágio do pipeline manipula apenas uma sequência vazia ou uma coleção vazia. Se você inserir uma string vazia no início, obterá uma lista vazia no final. Você não precisa parar e procurar nulluma exceção após cada chamada.

Obviamente, isso pressupõe que uma lista de saída vazia não tenha mais de um significado. Se você precisar diferenciar entre uma saída vazia causada pela entrada vazia e uma causada pela própria transformação, isso muda completamente as coisas.

Esta questão é realmente sobre exceções. Se você olhar dessa maneira e ignorar a coleção vazia como um detalhe de implementação, a resposta é direta:

1) Um método deve lançar uma exceção quando não puder prosseguir: incapaz de executar a tarefa designada ou retornar o valor apropriado.

2) Um método deve capturar uma exceção quando é capaz de prosseguir, apesar da falha.

Portanto, seu método auxiliar não deve ser "útil" e gerar uma exceção, a menos que seja incapaz de fazer seu trabalho com uma coleção vazia. Deixe o chamador determinar se os resultados podem ser tratados.

Se ele retorna uma coleção vazia ou nula, é um pouco mais difícil, mas não muito: coleções anuláveis ​​devem ser evitadas, se possível. O objetivo de uma coleção anulável seria indicar (como no SQL) que você não tem as informações - uma coleção de filhos, por exemplo, pode ser nula se você não souber se alguém tem alguma, mas você não sabe que eles não. Mas se isso é importante por algum motivo, provavelmente vale uma variável extra para acompanhá-lo.

O método é nomeado TransformNodes. No caso de uma coleção vazia como entrada, recuperar uma coleção vazia é natural e intuitiva e faz sentido matemático.

Se o método foi nomeado Maxe projetado para retornar o elemento máximo, seria natural lançar NoSuchElementExceptionuma coleção vazia, pois o máximo de nada não faz sentido matemático.

Se o método foi nomeado JoinSqlColumnNamese projetado para retornar uma sequência em que os elementos são unidos por uma vírgula para uso em consultas SQL, faria sentido lançar IllegalArgumentExceptionuma coleção vazia, pois o chamador acabaria recebendo um erro SQL de qualquer maneira, se usasse a string em uma consulta SQL diretamente, sem mais verificações e, em vez de procurar uma string vazia retornada, ele realmente deveria ter verificado a coleção vazia.

Vamos voltar e usar um exemplo diferente que calcula a média aritmética de uma matriz de valores.

Se a matriz de entrada estiver vazia (ou nula), você pode atender razoavelmente à solicitação do chamador? Não. Quais são suas opções? Bem, você poderia:

• presente / retornar / lançar um erro. usando a convenção da sua base de código para essa classe de erro.
• documento que um valor como zero será retornado
• documento que um valor inválido designado será retornado (por exemplo, NaN)
• documentar que um valor mágico será retornado (por exemplo, um mínimo ou um máximo para o tipo ou algum valor potencialmente indicativo)
• declarar o resultado não especificado
• declarar a ação indefinida
• etc.

Eu digo que dê a eles o erro se eles fornecerem uma entrada inválida e a solicitação não puder ser concluída. Quero dizer, um erro grave desde o primeiro dia, para que eles entendam os requisitos do seu programa. Afinal, sua função não está em posição de responder. Se a operação pode falhar (por exemplo, copiar um arquivo), então a sua API deve dar-lhes um erro eles podem lidar.

Portanto, isso pode definir como sua biblioteca lida com solicitações malformadas e solicitações que podem falhar.

É muito importante que o seu código seja consistente na maneira como lida com essas classes de erros.

A próxima categoria é decidir como sua biblioteca lida com solicitações sem sentido. Voltando a um exemplo semelhante à sua - vamos usar uma função que determina se um arquivo existe em um caminho: bool FileExistsAtPath(String). Se o cliente passa uma cadeia vazia, como você lida com esse cenário? Que tal uma matriz vazia ou nula passada para void SaveDocuments(Array<Document>)? Decida sua biblioteca / base de código e seja consistente. Por acaso, considero esses erros de casos e proíbo os clientes de fazer solicitações sem sentido, sinalizando-os como erros (por meio de uma asserção). Algumas pessoas resistem fortemente a essa idéia / ação. Acho essa detecção de erro muito útil. É muito bom para localizar problemas em programas - com boa localidade para o programa ofensivo. Os programas são muito mais claros e corretos (considere a evolução da sua base de código) e não queimam ciclos em funções que não fazem nada. O código é menor / mais limpo dessa maneira, e as verificações geralmente são enviadas para os locais onde o problema pode ser introduzido.

Como regra geral, uma função padrão deve ser capaz de aceitar a lista mais ampla de entradas e fornecer feedback sobre ela; existem muitos exemplos em que os programadores usam funções de maneiras que o designer não havia planejado, com isso em mente, acredito que a função deve ser capaz de aceitar não apenas coleções vazias, mas uma ampla variedade de tipos de entrada e retornar um retorno gracioso, mesmo que seja um objeto de erro de qualquer operação realizada na entrada ...