Do you use null often? And we have it in the specification

Nowadays, the downsides of using null as return types or passing them as an argument have become apparent to most developers.





Younger developers, even if they don't understand, usually follow "clean code" (after reading a book by Robert Martin). Therefore, code with the possibility of NPE occurrence has become less common, although, of course, they are.





I don’t want to say that any use of null is bad, but rather, you can say "measure seven times, cut once".





Nevertheless, I haven't complained about NPE for a long time, even when developers from languages ​​with strict control on this topic boasted about their null-safety. But because of one bug, I realized that just using null is not so bad, even if you return or pass it. Of course, this is very bad, but there are worse things - null in the specs.





It wouldn't be particularly interesting if the story was about one company that made a bad specification. Let's instead talk about the more well-known specification from Java EE - the Java Servlet Specification , specifically take the HttpServletRequest class and look into the methodgetCookies()







getCookies





Cookie[] getCookies()
      
      



Returns an array containing all of the Cookie



objects the client sent with this request. This method returns null



if no cookies were sent.





  • Returns:





    an array of all the Cookies



    included with this request, or null



    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]





I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language ( ALGOL W ). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years








All Articles