Java: Est-il ok pour définir Integer = null?

J'ai une fonction qui renvoie un numéro d'identification si l'argument existe dans la base de données. Sinon, elle renvoie la valeur null. Est-ce la mendicité pour une exception de pointeur null? Des numéros d'id négatifs ne sont pas autorisés, mais j'ai pensé qu'il serait plus clair d'avoir inexistante arguments de retourner la valeur null au lieu d'un code d'erreur comme -1. Qu'en 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?
}

Vous instruction return peut être plus court: résultat de retour.next() ? résultat.getInt("tid") ? null;
Plus court != plus lisible
Convenu en général, mais il serait beaucoup lu de mieux dans l'exemple ci-dessus.

OriginalL'auteur Nick Heiner | 2010-01-24

15

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

Grand point, il y a effectivement danger que l'appelant effectuer un faux calcul. C'est pourquoi je pense que la documentation est si important. Comme je l'ai mentionné dans ma réponse, si j'ai déjà le document le type de retour, je pourrais aussi bien le faire null
Dans Java 8 (encore quelques années, quand la question a été posée de), vous devez utiliser Optional<Integer> à cette fin. En ajoutant ce commentaire ici, sur la a accepté de répondre au cas où quelqu'un tombe sur cette.
En fait, OptionalInt.

OriginalL'auteur FRotthowe
3

Retour d'un null dans le cas d'une recherche qui ne donne pas de résultat est une méthode normale de représentant de la non-existence. Je le choisir dans ce cas. (Méthodes de recherche pour le standard Java Carte de classes sont un exemple pour l'utilisation de null dans le cas où la carte ne contient pas de clé).

Comme pour renvoyer une valeur spéciale pour le code, je ne propose de le faire si votre système contient déjà des valeurs spéciales repesenting d'identité spéciale.

Autre souvent entendu possibilité est de lancer une exception dans ce cas. Il n'est pas sage cependant utiliser les exceptions pour passer de l'état, je ne voudrais pas le faire.

Quant à votre dernière phrase: Pourquoi n'est-il pas sage d'utiliser les exceptions pour passer de l'état, et dans quel état serait passé dans ce cas?
Dans le cas présent, le passé de l'état serait la non-existence du nom de la table. Les Exceptions sont destinés à représenter des situations exceptionnelles qui ne se produisent pas normalement, tandis que l'état est passé lors de l'exécution normale - utilisation de la méthode des arguments et valeurs de retour pour le passage de l'état. (Et le déroulement de pile par les exceptions lancées est moins performant qu'une valeur de retour.)

OriginalL'auteur rsp
2

Je pense qu'il est légitime de retourner la valeur null dans ce cas. Assurez-vous que l'intention est documenté correctement.

De retourner une valeur négative serait dans ce cas ok, mais il n'est pas une solution. Que faire si les valeurs négatives ont été autorisés dans la db?

MODIFIER: je voudrais ajouter un mot à propos des débats sur DONC en ce qui concerne le retour des valeurs null ou vide listes (ou tableaux). Je suis en faveur d'un retour à vide des listes 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, null a un sens (= pas trouvé) et il n'y a pas de raison pour éviter de se retrouver.

OriginalL'auteur Yoni
1

J'espère que ce n'est pas une véritable méthode pour vous. Vous n'êtes pas en état de fermeture ou de jeu de résultats dans la portée de la méthode.

De bons points, mais cela n'est pas vraiment une réponse à la question.
Correct, mais il ya des moments où coller à la question n'est pas la meilleure politique. D'autres ont donné une très bonne réponse qui répond à la lettre de la loi. Pourquoi tout simplement le répéter?
Je pense que @TM point était pour faire allusion vous devez avoir posté un commentaire et pas de réponse.
oui, je sais ce que le point a été. Je n'arrive pas à être d'accord avec elle. Ce que j'ai dit est tout à fait correcte et appropriée, et si je l'ai mis dans une réponse ou un commentaire ne semble pas pertinent pour moi. Pourquoi devrait-il question?
parce que si vous le mettez dans une réponse quand elle n'a rien à voir avec la question de son claire de votre pêche à la traîne pour rep. meta.stackexchange.com/questions/17447/...

OriginalL'auteur duffymo
1
- Ne pas utiliser un code d'erreur! Dont la valeur est l'erreur? il n'est jamais devenu un juridiques valeur de retour? Rien gagné.
- Null n'est pas bon. La plupart de l'appelant code avoir à faire si ce n'null vérifier le résultat. Et quelques fois le select peut retourner la valeur null. Devrait-il être manipulé différents qu'aucune ligne?
- Lever une exception comme NoSuchElementException au lieu de le renvoyer null. C'est un décoché exception, l'appelant peut le manipuler ou de le laisser passer. Et si l'appelant veut traiter, le try catch n'est pas plus complexe qu'une, si pas la valeur null.
OriginalL'auteur Arne Burmeister
1

Je vous suggère d'envisager l'option motif.

L'option motif agit comme un wrapper autour de votre retour type, et définit deux cas particuliers: l'option.none (aucun) et à l'option.certains(). De cette façon, vous connaissez toujours retourné type (option), et pouvez vérifier si vous avez une valeur dans le retour de l'Option objet à l'aide de méthodes telles que l'option.isSome() et option.isNone().

De cette façon, vous pouvez garantir que vous n'avez pas décoché les valeurs null.

Bien sûr, tout cela se fait au prix d'un code supplémentaire de complexité.

Pour plus d'informations sur le type de l'option, voir ici (Scala code, mais même principal)

OriginalL'auteur Chaos
0

Non, il ne sera pas. Il ne fera que jeter un NPE si vous ne les opérations sur elle par la suite que si elle est une primitive sans nullchecking. E. g. i++ et ainsi de suite. Votre exemple est valide (attendez-vous à partir de ce code JDBC lui-même est une fuite de ressources). Si vous n'avez pas besoin du réel id, alors vous pouvez aussi le juste retour d'un boolean.

OriginalL'auteur BalusC
0

Il peut causer de gros problèmes pour les utilisateurs novices. Les bons programmeurs de reconnaître que si le nom est invalide alors null peuvent être retournées. Avoir dit que le plus standard, c'est de jeter un peu de exception.

OriginalL'auteur fastcodejava
0

Peut être difficile dans la combinaison de l'autoboxing.
Si je fais cela:
```
final int tid = tidForTerm("term");
```
Et "durée" n'existe pas, je vais obtenir un NPE, parce que Java tente de unbox un Entier (null) pour une primitive int.

Néanmoins, il y a des cas où c'est en fait une bonne utilisation de null pour les Entiers. Dans des entités ayant en option int valeurs, par exemple la population d'une ville. Dans ce cas, la valeur null signifie, pas d'information disponible.

OriginalL'auteur whiskeysierra
0

Un problème intéressant et un grand nombre de solutions possibles:
1. Créer un HasArgument méthode et obliger les utilisateurs à appeler, ce problème peut être lente et dupplicate travail
2. Lever une exception si une valeur n'est pas dans la base de données doit être utilisé uniquement si c'est inattendu
3. Utiliser d'autres valeurs pour indiquer un retour non valide, nulle et les valeurs négatives serait travailler pour vous, mais si non coché, ils pourraient causer des problèmes plus tard dans le code.
4. Retour d'une cape avec une isValid() et un getValue() la méthode, où getValue() lève une exception quand il est invalide. Cela permettrait de résoudre les problèmes de la 1 et la 3, mais peut-être un peu trop mutch.
OriginalL'auteur josefx
0

Je dirais que la meilleure solution dépend de ce que votre méthode est nommée, et vous devriez considérer ce que vos méthodes sont nommés d'autant que s'ils doivent retourner la valeur null ou lever une exception.

tidOfTerm implique pour moi que le Terme est prévu d'exister, de découvrir que l'un n'existe pas doit lever une exception.

Si le nom est sous le contrôle de votre propre code, et ne pas trouver il indique un bug dans votre code ou de l'environnement, alors vous pourriez vouloir jeter un IllegalArgumentException.

Si le terme nom de l'argument n'est pas sous votre contrôle, et de ne pas trouver un terme valide est parfaitement valable de la situation, alors je voudrais renommer votre méthode pour quelque chose comme findTidForTermName donnant un léger soupçon que certains types de recherche va être effectuée, et qu'il est donc de la possibilité que la recherche pourrait ne pas trouver quoi que ce soit.

OriginalL'auteur Stephen Denne
-3

Je suis d'accord avec les affiches. Entier est un wrapper et, comme telle, doit être utilisée pour les calculs, conversions, etc (je pense que vous avez l'intention de le faire). Ne retourne pas une valeur null, utilisez un nombre négatif... c'est un peu plus élégant et permet plus de contrôle. À mon humble avis.

on risque de faire des calculs, des conversions, etc avec le nombre négatif si l'on oublie de les vérifier. Si l'on ne vérifie pas les nombres négatifs, on pourrait ainsi vérifier la valeur null.

OriginalL'auteur Josh Molina
-3

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

Envisager de revenir une liste contenant le nombre de valeurs de retour, qui pourrait être de zéro.

Comment est le retour d'une Liste de" pertinent lorsque le type de retour est de type Entier?
De retour null est parfaitement valide, et très commun parmi les innombrables Api. Aussi longtemps que vous le document, c'est absolument la bonne chose à faire.
D'innombrables entrées en phase nationale ont eu lieu à partir de programmeurs de ne pas vérifier la valeur de retour contre null à partir de ces API. En outre, lorsque vous avez un `a().b().c()' de la construction en ligne vous ne pouvez pas dire tout de suite laquelle des appels a donné l'exception NullPointerException. Je pense que Jetbrains sont tout à fait raison dans leur @NotNull annotation. jetbrains.com/idea/documentation/howto.html
dans ce cas particulier, vous ne pouvez pas et un changement serait nécessaire. Ne vous en accord ou en désaccord avec l'attitude à l'égard des valeurs de retour null?
Ressemble dans le cas présent, la méthode retourne un id, une clé primaire. C'est comment Hibernate est la marque d'une instance comme étant non enregistrées: onjava.com/pub/a/onjava/2006/09/13/.... Est Hibernate, tout à fait tort? Je ne le pense pas.

OriginalL'auteur Thorbjørn Ravn Andersen
-3

Oui il faut être à l'origine d'une NPE et Oui, vous devriez être en rattrapage que dans l'appel de la méthode (ou un autre endroit approprié). La raison la plus probable pour laquelle votre méthode retourne NULL quand il n'y a aucune dossiers et la bonne façon de gérer cela est de lancer une exception. Et le parfait exception de dire à quelqu'un que vous n'avez pas ce qu'il a demandé est NPE.

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

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

b) dans le futur si -1 devient un terme juridique id, alors il sera difficile de le changer (si vous devez utiliser -1, alors (EDIT: en C) au moins faire #define code d'erreur -1 et l'utilisation ERRORCODE partout)

Avez-vous fait juste suggérer d'utiliser des #define dans une Java question? (J'ai presque -1)
-1 pour suggérer à jeter des NPE.
Ne vous disons pas de jeter un NPE. Mais vous devriez heureux de retourner la valeur null et poignée dans la fonction appelante. Si vous avez accès dans la fonction appelante lorsqu'elle est nulle, vous devez attraper les NPE et de travailler à partir de là. Pense que je ne l'avais pas précisé dans le post original, mais vous avez ma dérive.
Oups

OriginalL'auteur alexloh

Vous devez vous connecter pour publier un commentaire.