De nos jours, les inconvénients de l'utilisation de null comme types de retour ou de leur transmission comme argument sont devenus évidents pour la plupart des développeurs.
Les jeunes développeurs, même s'ils ne comprennent pas, suivent généralement le «code propre» (après avoir lu un livre de Robert Martin). Par conséquent, le code avec la possibilité d'occurrence NPE est devenu moins courant, bien que, bien sûr, ils le soient.
Je ne veux pas dire que toute utilisation de null est mauvaise, mais plutôt, vous pouvez dire "mesurer sept fois, couper une fois".
Cependant, je ne me suis pas plaint de NPE depuis longtemps, même lorsque les développeurs de langages avec un contrôle strict sur ce sujet se vantaient de leur sécurité nulle. Mais à cause d'un bug, j'ai réalisé que le simple fait d'utiliser null n'est pas si mal, même si vous le renvoyez ou le transmettez. Bien sûr, c'est très mauvais, mais il y a des choses pires - nulles dans les spécifications.
Ce ne serait pas particulièrement intéressant si l'histoire portait sur une entreprise qui a fait une mauvaise spécification. Parlons plutôt de la spécification la plus connue de Java EE - Spécification de servlet Java , prenons spécifiquement la classe HttpServletRequest et examinons la méthodegetCookies()
getCookies
Cookie[] getCookies()
Renvoie un tableau contenant tous les Cookie
objets envoyés par le client avec cette demande. Cette méthode renvoie null
si aucun cookie n'a été envoyé.
Retour:
an array of all the
Cookies
included with this request, ornull
if the request has no cookies
:
This method returns
null
if no cookies were sent.
, , null. :
, , -, , .
null
, , . ? , ?
null vs empty array
null
, , :
API, null-check
- , getCookies() null .
. ,
null
( )
, , . null , , ( ).
, .
-, , . , , , .
-, (, - )
, null
for (Cookie cookie : httpServletRequest.getCookies()) {
// NPE! // …
}
int cookiesSize = httpServletRequest.getCookies().length // NPE!
null-check:
if (httpServletRequest.getCookies() != null)
for (Cookie cookie : httpServletRequest.getCookies()) {
// …
}
Cookie[] cookies = httpServletRequest.getCookies();
int cookiesSize = cookies == null ? 0 : cookies.length
, , NPE . , .
API, . Jetty
, , .
,
:
return cookies == null?null:cookies.getCookies();
:
if (cookies == null || cookies.getCookies().length == 0)
return null;
return _cookies.getCookies();
, .
, , . null
, , null
. , .
!
, , , . , ? , ?
, classpathx
The GNU Classpath Extensions project, aka classpathx builds free versions of Oracle's Java extension libraries, the packages in the
javax
namespace. It is a companion project of the GNU Classpath project.
" "
Cookie[] getCookies()
Gets all the Cookies present in the request.
Returns:
an array containing all the Cookies or an empty array if there are no cookies
Since:
2.0
. null
. , Sonar, SEI CERT Oracle Coding Standart for Java
. , , , .
.
- , null . , , , , . , .
, , , . null , .
- ( ):
- ,
. - , , .
, , .
Speaking at a software conference in 2009, Tony Hoare apologized for inventing the null reference:[25]
J'appelle cela mon erreur d'un milliard de dollars. C'était l'invention de la référence nulle en 1965. À cette époque, je concevais le premier système de type complet pour les références dans un langage orienté objet ( ALGOL W ). Mon objectif était de m'assurer que toute utilisation de références devait être absolument sûre, avec une vérification effectuée automatiquement par le compilateur. Mais je n'ai pas pu résister à la tentation de mettre une référence nulle, simplement parce que c'était si facile à mettre en œuvre. Cela a conduit à d'innombrables erreurs, vulnérabilités et pannes système, qui ont probablement causé un milliard de dollars de douleur et de dommages au cours des quarante dernières années.