J'ai une En supposant fonction avec la signature suivante:ne renvoie rien, en utilisant array == null ou array.length == 0?
Foo[] getSomeFoos()
{
//return null --- option A
or
//return new Foo[0]; --- option B
}
Quelle est la pratique recommandée pour renvoyer la valeur indiquant qu'il n'y a pas d'éléments retournés? Des avantages ou des inconvénients pour chaque option?
Si votre méthode GetSomeFoos() a réellement 'trouvé' 0 éléments, alors elle doit renvoyer new Foo[0].
S'il y avait une sorte d'erreur, vous devriez lancer un Exception.
La raison est que les utilisateurs ne devraient pas avoir à chercher nulls:
for (Foo f: GetSomeFoos()) {
// do stuff
}
Dans le cas ci-dessus, si GetSomeFoos retourné null, un utilisateur devra faire face à un NullPointerException. Mais, si vous renvoyez un tableau vide, le code n'entre jamais dans la boucle et l'utilisateur n'aura pas à gérer une exception.
return null peut être raisonnable. Je l'utiliserais pour signifier qu'il n'y a aucun genre de Foo qui pourrait être retourné. Dans tous les autres cas, retourner un tableau vide est le plus judicieux. – Joshua
@Joshua, je suppose que je pourrais penser à une raison pour laquelle je pourrais retourner null. Mais habituellement, je retournerais une liste vide/tableau vide. – jjnguy
Le fait de renvoyer un objet nul ou vide dépend entièrement de l'utilisation de la méthode. Si cette méthode est appelée par un client et exposée en tant qu'API, l'exception de lancement est meilleure, mais si elle est utilisée dans le paquetage ur et jamais utilisée par le client, le retour de null est correct. –
Le fait de renvoyer un objet vide ou vide dépend entièrement de l'utilisation de la méthode. Si cette méthode est appelée par un client et exposée en tant qu'API, l'exception de lancement est meilleure, mais si elle est utilisée dans le paquetage ur et jamais utilisée par le client, le retour de null est correct.
Renvoyer la valeur null est plus efficace, car vous évitez le surcoût lié à la création d'un nouvel objet tableau ou collection. Il est vrai que vous devez ensuite ajouter une vérification nulle au point où vous utilisez la sortie de la fonction, mais le surcoût pour cela (en Java et presque toutes les langues) est négligeable. Je pense aussi que la vérification de null est une bonne habitude à prendre, en particulier lorsqu'il s'agit de bibliothèques tierces. L'inconvénient est que vous rendez le code plus bavard.
Si vous renvoyez un tableau vide, vous pouvez atténuer le problème de performances en réutilisant le même objet. Créer une constante immuable, et le retour que:
private static final String[] EMPTY = {};
Ou:
private static final List<String> EMPTY =
Collections.unmodifiableList(new ArrayList<String>());
Vous soutenez le gain de performance entre: 'return null' et' return new Object [0] '? Je ne peux pas croire que l'allocation de 0 espace prend beaucoup plus de temps que ne pas allouer de l'espace. (Attendez, y a-t-il une différence?) – jjnguy
L'optimisation prématurée est la racine de tout mal. Ne rentrez pas null, certainement pas pour cette raison. –
Il y a une grande différence. Un tableau Java est un objet - ce n'est pas comme C, où un tableau est juste un pointeur vers un bloc alloué sur le tas. Vous devez allouer de l'espace pour l'objet tableau et l'initialiser, même s'il contient zéro élément. –
Je préfère tableau zéro taille.
Il est plus sûr (éviter les NPE) et plus facile (pas besoin de vérifier les valeurs nulles).
De Effective Java (2nd ed) - article 43: retour des tableaux ou des collections vides, non NULLS
En résumé, il n'y a plus aucune raison de revenir nulle d'une méthode ou array- valeur est une collection au lieu de retourner un tableau vide ou une collection
Voir [ Est-ce que la valeur null est incorrecte? ] (http://stackoverflow.com/questions/1274792/is-returning-null-bad-design) –
Utilisez des collections et non des tableaux. – ColinD