Java: Tudo bem definir o número inteiro = nulo?

StackOverflow https://stackoverflow.com/questions/2128409

Pergunta

Eu tenho uma função que retorna um número de identificação se o argumento existir no banco de dados. Caso contrário, ele retorna nulo. Isso está implorando por uma exceção de ponteiro nulo? Os números de ID negativos não são permitidos, mas achei que seria mais claro ter argumentos inexistentes retornando nulo em vez de um código de erro como -1. O que você acha?

private Integer tidOfTerm(String name) throws SQLException {
    String sql = "SELECT tid FROM term_data WHERE name = ?";
    PreparedStatement prep = conn.prepareStatement(sql);
    prep.setString(1, name);
    ResultSet result = prep.getResultSet();

    if (result.next()) {
        return result.getInt("tid");
    }

    return null; // TODO: is this begging for a null pointer exception?
}
Foi útil?

Solução

Isso é perfeitamente legal. Se você deseja evitar um NPE, faça uma exceção personalizada. Mas não retorne um número negativo. Se o chamador não verificar o valor de retorno, você sempre terá um problema. Mas fazendo falso O cálculo (porque o resultado é, por exemplo, multiplicado por -1) é definitivamente mais difícil de depurar do que uma exceção despachada.

Outras dicas

Retornando a null No caso de uma pesquisa que não fornece um resultado, é um método normal de representar inexistência. Eu escolheria neste caso. (Os métodos de pesquisa para as classes de mapa Java padrão são um exemplo para o uso de null Caso o mapa não contenha uma chave.)

Quanto ao retorno de um valor especial para o ID, eu apenas proponha fazer isso se o seu sistema já contiver valores especiais que representam IDs especiais.

Outra possibilidade muitas vezes ouvida é lançar uma exceção neste caso. No entanto, não é sábio usar exceções para aprovar o estado, então eu também não faria isso.

Eu acho que é legítimo retornar nulo neste caso. Apenas certifique -se de que a intenção esteja documentada corretamente.

Retornar um valor negativo nesse caso seria bom, mas não é uma solução geral. E se valores negativos fossem permitidos no banco de dados?

EDITAR: Quero adicionar uma palavra sobre as discussões relacionadas sobre o retorno de nulos ou listas vazias (ou matrizes). Sou a favor de retornar listas ou matrizes vazias em vez de nulas, mas o contexto é diferente. Ao tentar obter uma lista, ela geralmente faz parte de um objeto pai e faz sentido que o objeto pai tenha uma lista vazia em vez de uma referência nula. Nesse caso, Null tem um significado (= não encontrado) e não há razão para evitar devolvê -lo.

Espero que não seja um método real para você. Você não está fechando a declaração ou o conjunto de resultados no escopo do método.

  • Não use um código de erro! Qual valor é o erro? Isso nunca se tornará um valor de retorno legal? Nada venceu.

  • Nulo não é bom. A maioria do código do chamador precisa fazer uma verificação nula do resultado. E algumas vezes a seleção pode retornar nulo. Deveria ser tratado diferente de nenhuma linha?

  • Jogue uma exceção como NosuchElementException em vez do retorno nulo. É uma exceção desmarcada, o chamador pode lidar com isso ou passar. E se o chamador quiser lidar, a captura de tentativa não será mais complexa do que um, se não nulo.

Eu sugiro que você considere o padrão de opção.

O padrão de opção atua como um invólucro em torno do seu tipo retornado e define dois casos especiais: option.none () e option.some (). Dessa forma, você sempre conhece o seu tipo de retorno (uma opção) e pode verificar se você tem um valor no objeto de opção retornado usando métodos como option.issome () e option.isnone ().

Dessa forma, você pode garantir que você não possui nulos sem controle.

Obviamente, tudo isso tem o custo de complexidade adicional de código.

Para mais informações sobre o tipo de opção, consulte aqui (Código Scala, mas o mesmo principal)

Não, não vai. Ele só lançará um NPE se você fizer operações depois como se fosse um primitivo sem que você escreva. Por exemplo i++ e assim por diante. Seu exemplo é válido (espere que o próprio código JDBC esteja vazando recursos). Se você não precisa do real id, então você pode, por outro lado, também apenas devolver um boolean.

Pode causar grandes problemas para usuários iniciantes. Bons codificadores reconhecerão que se o nome for inválido, então null pode ser devolvido. Dito que a coisa mais padrão é jogar alguns exception.

Pode ser complicado em combinação de auto -boxamento. Se estou fazendo isso:

final int tid = tidForTerm("term");

E "termo" não existe, vou obter um NPE, porque o Java tenta unir um número inteiro (nulo) para um Int primitivo.

No entanto, há casos em que é realmente bom usar nulo para números inteiros. Nas entidades com valores op opcionais, por exemplo, a população de uma cidade. Nesse caso, Null significaria que nenhuma informação disponível.

Um problema interessante e um grande número de soluções possíveis:

  1. Crie um método Hasarment e exija
  2. Jogue uma exceção se um valor não estiver no banco de dados, só deve ser usado se isso for inesperado
  3. Use valores adicionais para indicar um retorno inválido, valores nulos e negativos funcionariam para você, mas se não marcar, eles poderiam causar problemas posteriormente no código.
  4. Retorne um invólucro com um método ISValid () e GetValue (), onde getValue () joga uma exceção quando é inválido. Isso resolveria os problemas de 1 e 3, mas pode ser um pouco vira -lata demais.

Eu diria que a melhor solução depende do nome do seu método e você deve considerar o nome dos seus métodos tanto quanto se eles devem retornar nulos ou lançar uma exceção.

tidOfTerm implica para mim que o termo deve existir, portanto, descobrir que não existe deve fazer uma exceção.

Se o nome do termo estiver sob o controle do seu próprio código e não encontrá -lo indica um bug no seu código ou ambiente, convém lançar uma ilegalArgumentException.

Se o argumento do nome do termo não estiver sob seu controle, e não encontrar um termo válido é uma situação perfeitamente válida, então eu renomearia seu método para algo como findTidForTermName dando uma pequena dica de que algum tipo de pesquisa será executada e que existe, portanto, a possibilidade de a pesquisa não encontrar nada.

Eu concordo com os pôsteres. O número inteiro é um invólucro e, como tal, deve ser usado para cálculos, conversões etc. (o que acho que você pretende fazer). Não devolva um NULL, use um número negativo ... É um pouco mais elegante e permite mais controle. NA MINHA HUMILDE OPINIÃO.

Por favor, não escreva código que retorne nulo. Isso significa que cada chamada para seu código DEVO Verifique se há NULL para ser robusto. Toda vez. Sempre.

Considere devolver uma lista, em vez disso, contém o número de valores de retorno, que podem ser zero.

Sim, deve estar causando um NPE e sim, você deve estar pegando isso no método de chamada (ou em algum outro local adequado). A razão mais provável pela qual seu método retornará nulo é quando não há registros e a maneira correta de lidar com isso é lançar uma exceção. E a exceção perfeita para dizer a alguém que você não tem o que ele pediu é o NPE.

Retornar um código de erro (por exemplo -1) não é bom porque:

a) Se houver muitos erros que você deseja manusear (por exemplo, não é possível ler o banco de dados, pode ler o banco erros.

b) No futuro, se -1 se tornar um ID de termo legal, será difícil alterá -lo (se você precisar usar -1, então (editar: em c) pelo menos fazer #define errorcode -1 e use ErrorCode em todos os lugares)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top