[JAVA] À propos de la gestion de Null

Je pense que beaucoup de gens peuvent trouver la vérification nulle ennuyeuse en touchant le langage de développement. Je pense qu'il est normal de voir l'existence d'objets nuls, mais honnêtement, je pense qu'il est difficile à emballer même si vous regardez auto_ptr de C ++ / stl et Optional de java. Dans de telles circonstances, je suis très heureux d'essayer d'éliminer null au niveau de la langue comme kotlin.

Donc, j'aimerais réfléchir à la façon d'écrire du code qui ne rencontre pas null, donc j'écrirai ce qui me tient à cœur pour le moment

** Pourquoi détestez-vous null? ** **

La partie la moins appréciée de null est if (null === Je pense que le contexte est décrit comme un contexte qui n'a rien à voir avec la logique métier. Par conséquent, je pense à la beauté des différentes personnes qui ne peuvent être résumées que dans la logique métier.

** Cas d'emballage comme méthode courante d'évitement de null **

Tout d'abord, essayez de collecter des méthodes générales d'évitement nul pour autant que vous le souhaitez

*** Valeur de retour de la collection ***

*** Il n'est pas nécessaire d'effectuer une vérification nulle comme l'instruction if, il n'y a donc aucun sentiment d'inconfort dans la logique métier *** List/Array/Map En SQL etc., s'il n'y a pas de données lors de l'obtention du résultat, null peut être retourné. En utilisant List, Array, etc. comme valeur de retour, le contrôle nul peut être éliminé ou le nombre d'éléments peut être vérifié.

*** Facultatif *** et *** std :: auto_ptr ***

*** Au lieu d'un contrôle nul, un traitement de substitution est inséré, mais une valeur de substitution peut être entrée dans une instruction, de sorte que le sentiment d'inconfort dans la logique métier est atténué *** std::auto_ptr En C / C ++, l'opérateur opérateur peut être utilisé, il peut donc être utilisé sans gêne en fonction de l'application.

 int* pint = ptr.get();
```Etc., il y a un problème d'appropriation etc. et il faut faire attention à la méthode de mise en œuvre

[Optional](https://docs.oracle.com/javase/jp/8/docs/api/java/util/Optional.html)
 Même si je veux utiliser un objet, il me semble étrange d'appeler une méthode car elle est encapsulée.
 J'ai entendu dire qu'il est toujours utilisé uniquement comme valeur de retour, mais je pense qu'il est difficile de le recevoir comme valeur de retour et de l'attribuer à nouveau.

## *** Mono / Flux réactif ***
 *** Il n'est pas nécessaire d'effectuer une vérification nulle comme l'instruction if, donc il n'y a pas d'inconfort dans la logique métier ***
 [mono](http://projectreactor.io/docs/core/release/reference/#mono)
 Il dit "Émettez un élément au maximum", mais il l'enveloppe intentionnellement avec seulement 0 .. 1.
 [flux](http://projectreactor.io/docs/core/release/reference/#flux)
 Il dit "0 à N éléments" et représente intentionnellement 0 .. N.

# ** Cas où les conditions nulles ne sont pas décrites, comme NullObject **
## *** Existence d'exception et try / catch ***
 Récemment, en utilisant exception et try / catch, les erreurs de segmentation causées par des points nuls ont disparu, donc on peut dire que vous n'avez pas à vous soucier des objets nuls.

## *** S'il n'y a pas d'exception ***
 Lorsque la vérification NULL n'est pas effectuée, des fuites de mémoire se produisent fréquemment et peuvent provoquer un comportement involontaire.
 Par conséquent, il est nécessaire d'effectuer une gestion des erreurs appropriée après la vérification de null.

 ***null object***
 Lors du retour d'un objet, le retour d'un type (nul) autre que object entraînera une branche involontaire, mais si un seul objet est renvoyé, la logique peut se dérouler sans heurts.
 Cependant, comme il est nécessaire de renvoyer un comportement ou une exception dans toutes les méthodes, il peut être plus simple de lancer une exception NullPointerException normalement de nos jours sur le principe de try / catch.