Est-ce que renvoyer null bad design?

Question

J'ai entendu des voix dire que rechercher une valeur nulle renvoyée par une méthode est une mauvaise conception. J'aimerais entendre certaines raisons pour cela.

pseudocode:

 variable x = object.method()
if (x is null) do something
 

Answer 1

La logique derrière le fait de ne pas retourner la valeur null est que vous n'avez pas à vérifier et donc votre code n'a pas besoin de suivre un chemin différent en fonction de la valeur de retour. Vous pourriez vouloir vérifier l' Objet Null Modèle qui fournit plus d'informations sur cette.

Par exemple, si je devais définir une méthode en Java qui a retourné une Collection, je voudrais préfèrent généralement de retour d'un regroupement vide (c - Collections.emptyList()) plutôt que null car cela signifie que mon client code est plus propre; par exemple,

Collection<? extends Item> c = getItems(); // Will never return null.

for (Item item : c) { // Will not enter the loop if c is empty.
  // Process item.
}

... ce qui est plus propre que:

Collection<? extends Item> c = getItems(); // Could potentially return null.

// Two possible code paths now so harder to test.
if (c != null) {
  for (Item item : c) {
    // Process item.
  }
}

Answer 2

En voici la raison.

Dans le Code Propre par Robert Martin , écrit-il, que de retourner la valeur null est une mauvaise conception, quand on peut, au lieu de revenir, disons, tableau vide. Depuis le résultat attendu est un tableau, pourquoi pas? Il va vous permettre d'effectuer une itération sur le résultat, sans conditions supplémentaires. Si c'est un entier, peut-être 0 suffit, si c'est un hachage hachage vide. etc.

Le principe est de ne pas forcer le code appelant à traiter immédiatement les questions. Code appelant peut ne voulez pas à s'occuper d'eux. C'est aussi pourquoi, dans de nombreux cas, des exceptions est mieux que le néant.

Answer 3

Bons usages de retourner null:

• Si la valeur null est une valeur de la fonctionnelle de résultat, par exemple: FindFirstObjectThatNeedsProcessing() peut retourner la valeur null si pas trouvé, et l'appelant doit vérifier en conséquence.

De mauvais usages: Essayer de remplacer ou de masquer des situations exceptionnelles telles que:

• catch(...) et retourner la valeur null
• API dépendance échec de l'initialisation de
• Hors de l'espace disque
• Non valide les paramètres d'entrée (erreur de programmation, les entrées doivent être désinfectés par l'appelant)
• etc

Dans ces cas, la levée d'une exception est plus suffisant, étant donné que:

• Une valeur de retour null fournit pas d'erreur significatif info
• L'appelant immédiat le plus probable ne peut pas traiter la condition d'erreur
• Il n'y a aucune garantie que l'appelant est la vérification de résultats nuls

Toutefois, les Exceptions ne doivent pas être utilisés pour gérer normale du programme, les conditions d'exploitation telles que:

• Non valide le nom d'utilisateur/mot de passe (ou l'utilisateur a fourni des contributions)
• La rupture de la boucle ou de non-local gotos

Answer 4

Qui a dit que c'était un mauvais design?

La vérification des valeurs NULL est une pratique courante, même encouragée, sinon vous courez le risque de NullReferenceExceptions partout. Il vaut mieux gérer l'erreur correctement que de lancer des exceptions lorsque vous n'en avez pas besoin.

Answer 5

D'après ce que vous avez dit jusqu'à présent, je pense qu'il n'y a pas assez d'informations.

Renvoyer null depuis une méthode CreateWidget () semble mauvais.

Renvoyer null à partir d'une méthode FindFooInBar () semble correct.