Java: Est-il correct de définir Integer = null?

Question

J'ai une fonction qui renvoie un numéro d'identification si l'argument existe dans la base de données. Sinon, il renvoie la valeur null. Est-ce que cela élude une exception de pointeur nul? numéros d'identification négatifs ne sont pas autorisés, mais je pensais que ce serait plus clair d'avoir des arguments non existants retourner null au lieu d'un code d'erreur comme -1. Que pensez-vous?

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?
}

Answer 1

Ceci est parfaitement légal. Si vous voulez éviter un NPE, lancer une exception personnalisée. Mais ne renvoient pas un nombre négatif. Si l'appelant ne vérifie pas la valeur de retour, vous aurez toujours un problème. Mais faire false calcul (parce que le résultat est par exemple multiplié par -1) est certainement plus difficile à déboguer qu'une exception uncatched.

Answer 2

De retour d'un null dans le cas d'une recherche qui ne donne pas un résultat est une méthode normale de représentation non existance. Je choisirais dans ce cas. (Méthodes Lookup pour les classes Java standard Carte sont un exemple pour l'utilisation de null dans le cas où la carte ne contient pas de clé.)

En ce qui concerne le retour d'une valeur particulière pour l'ID, je propose que de le faire que si votre système contient déjà des valeurs spéciales repesenting de spéciales ID.

Une autre possibilité souvent entendu est de lancer une exception dans ce cas. Il est pas sage cependant d'utiliser des exceptions pour passer l'état, donc je ne ferais pas non plus.

Answer 3

Je pense qu'il est légitime de revenir nulle dans ce cas. Assurez-vous que l'intention est documenté correctement.

De retour une valeur négative dans ce cas serait ok, mais ce n'est pas une solution tout autour. Que faire si les valeurs négatives ont été autorisées dans le db?

EDIT : Je veux ajouter un mot au sujet des discussions connexes sur SO concernant le retour ou des listes vides nulls (ou tableaux). Je suis en faveur d'un retour des listes vides ou des tableaux au lieu de null, mais le contexte est différent. Lorsque vous essayez d'obtenir une liste, il est généralement partie d'un objet parent, et il fait réellement sens pour l'objet parent d'avoir une liste vide au lieu d'une référence null. Dans ce cas, nul a un sens (= non trouvé) et il n'y a aucune raison de ne pas le renvoyer.

Answer 4

J'espère que ce n'est pas une vraie méthode pour vous. Vous n'êtes pas Discours de clôture ou ResultSet portée de la méthode.

Answer 5

• Ne pas utiliser un code d'erreur! Quelle valeur est l'erreur? il sera jamais devenir une valeur de retour légal? Rien gagné.

• nul n'est pas bon. La plupart du code de l'appelant doivent faire un chèque si non nul pour le résultat. Et quelques fois la sélection peut retourner null. Faut-il être traité différent de pas de ligne?

• lever une exception comme NoSuchElementException au lieu de l'hypothèse nulle de retour. Il est une exception non contrôlée, l'appelant peut gérer ou passer. Et si l'appelant veut gérer, les prises d'essai n'est pas plus complexe qu'une sinon nulle.

Answer 6

Je vous suggère de considérer le modèle d'option.

Le modèle d'option agit comme une enveloppe autour de votre type retourné, et définit deux cas particuliers: option.none () et option.some (). De cette façon, vous savez toujours votre type retourné (une option), et peut vérifier si vous avez une valeur dans votre revenu objet d'options en utilisant des méthodes telles que option.isSome () et option.isNone ().

De cette façon, vous pouvez vous garantir n'avez pas encore nulls non vérifiées.

Bien sûr, tout cela se fait au détriment de la complexité du code supplémentaire.

Pour plus d'informations sur le type d'option, voir ( Code Scala, mais même principe)

Answer 7

Non, il ne sera pas. Il ne jeter un NPE si vous faites des opérations sur elle après que si elle est une primitive sans nullchecking il. Par exemple. i++ et ainsi de suite. Votre exemple est valide (attendre que le code JDBC lui-même est une fuite des ressources). Si vous n'avez pas besoin id réelle, alors vous pouvez d'autre part aussi juste revenir un boolean.

Answer 8

Il pourrait causer de gros problèmes pour les utilisateurs novices. De bons Coders reconnaître que si le nom est invalide, null peut être retourné. Cela dit que la chose plus standard est de jeter un peu exception.

Answer 9

peut être délicat en combinaison de Autoboxing. Si je fais ceci:

final int tid = tidForTerm("term");

« terme » n'existe pas, je vais obtenir un NPE, parce que Java essaie de unbox un entier (null) à un int primitif.

Cependant, il y a des cas où il est fait bon d'utiliser null pour Entiers. Dans les entités ayant des valeurs facultatives int, par exemple la population d'une ville. Dans ce cas, nul signifierait, aucune information disponible.

Answer 10

Un problème intéressant et un grand nombre de solutions possibles:

1. Créer une méthode HasArgument et obliger les utilisateurs à appeler, problème cela peut être lent et dupplicate
2. Lancer une exception si une valeur est pas dans la base de données, ne doit être utilisée si cela est inattendu
3. Utilisez des valeurs supplémentaires pour indiquer un retour non valide, les valeurs nulles et négatives fonctionnerait pour vous, mais sinon vérifié, ils pourraient causer des problèmes plus tard dans le code.
4. Retour d'une enveloppe avec un isValid () et une méthode getValue (), où getValue () renvoie une exception quand il est invalide. Cela résoudrait les problèmes de 1 et 3, mais peut-être un peu trop Mutch.

Answer 11

Je dirais que la meilleure solution dépend de ce que votre méthode est nommé, et vous devriez considérer ce que vos méthodes sont appelées autant que si elles doivent retourner nulle ou jeter une exception.

tidOfTerm me implique que le terme devrait exister, donc découvrir que l'on ne devrait pas exister lancer une exception.

Si le nom du terme est sous le contrôle de votre propre code, et ne pas trouver cela indique un bogue dans votre code ou de l'environnement, alors vous voudrez peut-être jeter un IllegalArgumentException.

Si l'argument nom du terme n'est pas sous votre contrôle, et de ne pas trouver un terme valide est une situation tout à fait valable, alors je renomme votre méthode pour quelque chose comme findTidForTermName donnant une légère allusion au fait que certains type de recherche va être réalisée, et qu'il n'y a donc la possibilité que la recherche pourrait ne pas trouver quoi que ce soit.

Answer 12

Je suis d'accord avec les affiches. Entier est une enveloppe et en tant que tel doit être utilisé pour les calculs, conversions, etc (que je pense que vous avez l'intention de le faire). Ne pas retourner un null, utilisez un nombre négatif ... il est un peu plus élégant et vous permet de mieux contrôler. À mon humble avis.

Answer 13

S'il vous plaît ne pas écrire du code qui renvoie null. Cela signifie que chaque appel à votre code MUST vérifier null pour être robuste. À chaque fois. Toujours.

Pensez à retourner une liste au lieu contenant le nombre de valeurs de retour, ce qui pourrait être nul.

Answer 14

Oui, il devrait être à l'origine d'un NPE et Oui, vous devriez captera que dans la méthode d'appel (ou un autre endroit approprié). La raison la plus probable pourquoi votre méthode retourne NULL est quand il n'y a pas de dossiers et la bonne façon de gérer c'est en lançant une exception. Et l'exception idéal pour dire à quelqu'un que vous n'avez pas ce qu'il demande est NPE.

De retour un code d'erreur (par exemple -1) n'est pas bon parce que:

a) s'il y a beaucoup d'erreurs que vous souhaitez gérer (par exemple, ne peut pas lire DB, peut lire DB, mais l'objet n'existe pas dans DB, objet trouvé, mais quelque chose est corrompu, etc.), puis retourner un code d'erreur ne fait pas la distinction entre les types d'erreurs.

b) à l'avenir si -1 devient un identifiant terme juridique, alors il sera difficile de le changer (si vous devez utiliser -1, puis (EDIT: en C) au moins faire ERRORCODE #define -1 et l'utilisation ERRORCODE partout)