Pourquoi devrait-on utiliser des Objets.requireNonNull()?

J'ai remarqué que beaucoup de Java 8 méthodes dans Oracle JDK utilisation Objects.requireNonNull(), qui en interne jette NullPointerException si l'objet donné (argument) est null.

public static <T> T requireNonNull(T obj) {
    if (obj == null)
        throw new NullPointerException();
    return obj;
}

Mais NullPointerException seront jetés de toute façon si un null objet est déréférencé. Alors, pourquoi doit-on faire cette null supplémentaires de vérifier et de les jeter
NullPointerException?

Une réponse évidente (ou l'avantage), c'est qu'il rend le code plus lisible et je suis d'accord. Je suis désireux de connaître toutes les autres raisons pour l'utilisation
Objects.requireNonNull() dans le début de la méthode.

InformationsquelleAutor user4686046 | 2017-08-11

157

Parce que vous pouvez faire des choses explicite en le faisant. Comme:
```
public class Foo {
  private final Bar bar;

  public Foo(Bar bar) {
    Objects.requireNonNull(bar, "bar must not be null");
    this.bar = bar;
  }
```
Ou moins:
```
  this.bar = Objects.requireNonNull(bar, "bar must not be null");
```
Maintenant, vous savoir:
- quand un objet Foo a été créé avec succès à l'aide de new()
- puis son bar champ est garanti être non null.
Comparez: vous créez un objet Foo aujourd'hui, et demain vous appelez une méthode qui utilise ce champ et le jette. Très probablement, vous ne saurez pas demain pourquoi cette référence est nulle hier quand il est passé au constructeur!

En d'autres termes: en utilisant explicitement cette méthode pour vérifier entrant des références que vous pouvez contrôle le point dans le temps lorsque l'exception est levée. Et la plupart du temps, vous voulez échouer aussi vite que possible!

Les principaux avantages sont:
- comme l'a dit, contrôlé comportement
- le débogage plus facile - parce que vous jetez dans le contexte de la création de l'objet. À un point dans le temps où vous avez une certaine chance que vos journaux/traces vous dire ce qui s'est passé!
- et comme indiqué ci-dessus: la vraie puissance de cette idée se déroule en collaboration avec final champs. Parce que maintenant tout autre code dans votre classe peut supposer qu' bar n'est pas nulle, et donc vous n'avez pas besoin de tout if (bar == null) vérifie dans d'autres endroits!
- Vous pouvez rendre votre code plus compact par écrit this.bar = Objects.requireNonNull(bar, "bar must not be null");
- L'enseignement GhostCat quelque chose de cool, je ne savais pas --> gagner un ticket dans le GhostCat upvote de loterie.
- Je pense que le commentaire #1 ici est le bénéfice réel de Objects.requireNonNull(bar, "bar must not be null");. Merci pour celui-ci.
- Bien sûr, c'est pourquoi j'ai édité ma réponse alors d'inclure cette chose, que je ne savais ou l'autre, ou l'une des personnes dans mon équipe 😉
- Sûr que si l'échec rapide est ce que nous allons pour nous pouvons toujours utiliser quelque chose comme la goyave est com.google.common.base.Preconditions#checkNotNull(T) qui, bien sûr, vous devez ajouter la goyave de la bibliothèque, mais pourquoi ne peuvent-ils suivre la goyave convention et de jeter un IllegalArgumentException
- Laquelle était la première, et pourquoi "la langue" les gens à suivre les auteurs de certains de la bibliothèque?! Pourquoi ne pas goyave suivre la Java lang comportement?!
- Le this.bar = Objects.requireNonNull(bar, "bar must not be null"); est ok dans les constructeurs, mais potentiellement dangereux dans d'autres méthodes, si deux ou plusieurs variables sont définies dans la même méthode. Exemple: talkwards.com/2018/11/03/...
InformationsquelleAutor GhostCat says Reinstate Monica
79

Fail-fast

Le code devrait planter dès que possible. Il ne faut pas faire la moitié du travail, puis de déréférencement de la valeur null et crash puis en laissant la moitié de travailler causant le système soit dans un état non valide.

Ce qui est communément appelé "l'échec précoce" ou "fail-fast".

InformationsquelleAutor luk2302
34

Mais NullPointerException seront jetés de toute façon si un objet nul est déréférencé. Alors, pourquoi doit-on faire cette null supplémentaires de vérifier et de les jeter NullPointerException?

Cela signifie que vous détecter le problème immédiatement et de manière fiable.

Considérer:
- La référence ne peut pas être utilisé jusqu'à tard dans la méthode, une fois votre code a déjà effectué certains effets secondaires
- La référence peut ne pas être déréférencés dans cette méthode à tous les
  - Il pourrait être passé complètement différents de code (c'est à dire la cause et l'erreur sont éloignés dans l'espace du code)
  - Il pourrait être utilisé beaucoup plus tard (c'est à dire la cause et l'erreur sont éloignés dans le temps)
- Il peut être utilisé quelque part qu'une référence null est valide, mais a un effet non intentionnel
.NET fait de mieux en séparant NullReferenceException ("vous déréférencé une valeur "null") à partir de ArgumentNullException ("vous ne devriez pas avoir passé dans la valeur null comme un argument - et c'est pour ce paramètre). Je souhaite que Java fait la même chose, mais même avec juste un NullPointerException, c'est encore beaucoup plus facile de corriger le code si l'erreur est jetée sur le premier point à partir duquel il peut être détecté.
- Mon upvote pour le morceau intéressant à partir de C# foncier 😉
InformationsquelleAutor Jon Skeet
8

À l'aide de requireNonNull() que les premières déclarations dans une méthode permettant d'identifier dès maintenant/rapide de la cause de l'exception.

La stacktrace indique clairement que l'exception a été levée dès que l'entrée de la méthode parce que l'appelant n'a pas respecté les exigences/contrat.
Le passage d'un null objet à une autre méthode peut en effet provoquer une exception à un moment, mais la cause du problème peut être plus compliqué à comprendre que l'exception sera levée dans une invocation sur le null objet qui peut être beaucoup plus loin.

Ici est un pas concret et réel exemple qui montre pourquoi nous avons à la faveur échouer rapidement, en général, et plus particulièrement à l'aide de Object.requireNonNull() ou de toute façon d'effectuer un pas de nulle vérifier les paramètres conçu pour être pas null.

Supposons qu'un Dictionary classe qui compose un LookupService et un List de String représentant les mots contenus dans. Ces champs sont conçus pour ne pas être null et l'un d'eux est passé dans le Dictionary constructeur.

Supposons maintenant qu'un "mauvais" de la mise en œuvre de Dictionary sans null vérifier dans la méthode d'entrée (ici est le constructeur):
```
public class Dictionary {

    private final List<String> words;
    private final LookupService lookupService;

    public Dictionary(List<String> words) {
        this.words = this.words;
        this.lookupService = new LookupService(words);
    }

    public boolean isFirstElement(String userData) {
        return lookupService.isFirstElement(userData);
    }        
}


public class LookupService {

    List<String> words;

    public LookupService(List<String> words) {
        this.words = words;
    }

    public boolean isFirstElement(String userData) {
        return words.get(0).contains(userData);
    }
}
```
Maintenant, nous allons appeler la Dictionary constructeur avec un null de référence pour la words paramètre :
```
Dictionary dictionary = new Dictionary(null); 

//exception thrown lately : only in the next statement
boolean isFirstElement = dictionary.isFirstElement("anyThing");
```
La JVM jette le NPE à cette déclaration :
```
return words.get(0).contains(userData); 
```
```
Exception in thread "main" java.lang.NullPointerException 
au LookupService.isFirstElement(LookupService.java:5) 
au Dictionnaire.isFirstElement(Dictionnaire.java:15) 
au Dictionnaire.principale(Dictionnaire.java:22) 
```
L'exception est déclenchée dans le LookupService classe alors que l'origine est bien antérieure (la Dictionary constructeur). Il rend l'ensemble de l'analyse de la question beaucoup moins évidente.

Est words null? Est words.get(0) null ? Les deux ?
Pourquoi l'un, l'autre ou peut-être les deux sont null ?
Est-ce une erreur de codage dans Dictionary (constructeur? méthode invoquée?) ? Est-ce une erreur de codage dans LookupService ? (constructeur? méthode invoquée?) ?

Enfin, nous aurons à inspecter plus de code pour trouver l'erreur d'origine et dans un complexe de classe peut-être même utiliser un débogueur pour comprendre plus facilement ce qui s'est passé.

Mais pourquoi une chose simple (un manque de nulle vérifier) deviennent un problème complexe ?

Parce que nous ont permis de bug/ne pas identifiable sur un composant spécifique de la fuite sur une baisse des composants.

Imaginez que LookupService n'était pas un local de service, mais un service à distance ou d'un tiers de la bibliothèque avec quelques informations de débogage ou imaginez que vous n'avez pas 2 couches, mais 4 ou 5 couches de l'objet invocations avant que le null être détecté ? Le problème serait encore plus complexe à analyser.

Ainsi, la manière de faveur est :
```
public Dictionary(List<String> words) {
    this.words = Objects.requireNonNull(words);
    this.lookupService = new LookupService(words);
}
```
De cette façon, pas de maux de tête : nous obtenons l'exception levée dès que celui-ci est reçu :
```
//exception thrown early : in the constructor 
Dictionary dictionary = new Dictionary(null);

//we never arrive here
boolean isFirstElement = dictionary.isFirstElement("anyThing");
```
```
Exception in thread "main" java.lang.NullPointerException 
à java.util.Objets.requireNonNull(les Objets.java:203) 
au com.De dictionnaire.(Dictionnaire.java:15) 
au com.De dictionnaire.principale(Dictionnaire.java:24) 
```
Notez qu'ici, j'ai illustré le problème avec un constructeur mais un appel de méthode pourrait avoir le même non-nulle de vérification de la contrainte.
- Wow! Grande explication.
InformationsquelleAutor davidxxx
2

Comme une note de côté, ce échouer rapidement avant de Object#requireNotNull a été mis en œuvre légèrement différentes avant de java-9 à l'intérieur de certains de la jre classes elles-mêmes. Supposons le cas :
```
 Consumer<String> consumer = System.out::println;
```
Dans java 8 cette compile comme (seulement les parties pertinentes)
```
getstatic Field java/lang/System.out
invokevirtual java/lang/Object.getClass
```
En gros, une opération comme : yourReference.getClass - ce qui serait un échec si yourRefercence est null.

De choses ont changé dans le jdk-9, où le même code compile comme
```
getstatic Field java/lang/System.out
invokestatic java/util/Objects.requireNonNull
```
Ou fondamentalement Objects.requireNotNull (yourReference)

InformationsquelleAutor Eugene
0

L'utilisation de base est de vérifier et de les jeter NullPointerException immédiatement.

Une meilleure alternative (raccourci) pour répondre à la même exigence est @Non null annotation par lombok.
- L'annotation n'est pas un remplacement pour les Objets de la méthode, ils travaillent ensemble. Vous ne pouvez pas dire @ Non x=mightBeNull, vous diriez @ Non x=Objets.requireNonNull(mightBeNull, "inconcevable!");
- désolé, je n'obtiens u
- Je viens de dire que le Non annotation fonctionne avec requireNonNull, il n'est pas une alternative, mais ils travaillent ensemble, assez bien.
- pour mettre en œuvre l'échec rapide de la nature, son une alternative à droite? Yh je suis d'accord ce n'est pas une alternative pour la cession.
- Je crois que je l'avais appeler requireNonNull() une "conversion" de @ Nullable à @ Non null. Si vous n'utilisez pas les annotations, la méthode n'est pas vraiment très intéressant (car il n'est de jeter un NPE tout comme le code il protège serait)--bien qu'il fait à peu montrer clairement votre intention.
InformationsquelleAutor Supun Wijerathne

Vous devez vous connecter pour publier un commentaire.

Fail-fast