In Java, return null is safe, why?

In Java code, return value NULL is not available in any case, why not throw nullpointerexception?

Java language level: The null value itself does not cause any problems. It's a quiet place to be (local variables, member fields, static fields) there is no problem; it can be transported from one place to another without any problems (variable assignment, return value, etc.). The only action that causes nullpointerexception because of a null value is the "dereference" (dereference)-that is, the object to which it is referenced by this reference. As the saying goes, the case of obj is a null value in all operations that imply "obj.xxx".
In Java, the following actions imply a reference to the dereference:

Read field (byte code GetField): x.y, when x is null, the NPE is thrown;
Write field (byte code putfield): x.y = Z, when x is null, the NPE is thrown. Note: The value of z is nothing okay;
Reading group Length (byte code arraylength): A.length, when a is null throw the NPE;
Reading group Element (byte code <x>aload,<x> type prefix): A[i], when a is null, the NPE is thrown;
Write array elements (byte code <x>astore,<x> prefix for type): a[i] = x, which throws the NPE when a is null. Note: The value of x does not matter;
Call the Member method (bytecode invokevirtual, Invokeinterface, invokespecial): Obj.foo (x, Y, z), and throw the NPE when obj is null. Note: The value of the parameter is what it doesn't matter;
Enhance A For loop (also called a Foreach Loop):
When an array (the actual implied a.length operation): for (E e:a) {...}, the NPE is thrown when a is null;
For iterable (actual implied call to Iterable.iterator ()): for (E e:es) {...}, when ES is null, the NPE is thrown;
Automatic unpacking (the actual implied <xxx>.<xxx>value () call,<xxx> for the wrapper type name,<xxx> to the corresponding original type name): (int) Integerobj, When integerobj is null, the NPE is thrown;
Make a switch to string (the actual implied action contains a call to String.hashcode ()): switch (s) {case "abc": ...}, and when S is null, the NPE is thrown;
Creates an inner class object instance (bytecode new, but this is specifically the case where an inner class instance is created): Outer.new Inner (x, Y, z), which throws the NPE when outer is null;
Throw exception (byte code athrow): Throw obj, when obj (argument of the throw expression) is null when the NPE is thrown;
Use the Synchronized keyword to give the object locking (bytecode Monitorenter/monitorexit): synchronized (obj) {...}, and when obj is null, the NPE is thrown.

All other syntactic constructs in the Java language do not implicitly throw the NPE semantics because of null values. Of course, users can explicitly check for null values where they want and then throw the NPE themselves, like this:

   
  
 
   

   
Java.util.Objects.requireNonNull (Object)
 
   

   
 
   

   
 /**
 
   

   
* Checks that the specified object reference are not {@code null}. This
 
   

   
* method is designed primarily for doing parameter validation in methods
 
   

   
* and constructors, as demonstrated below:
 
   

   
* <blockquote><pre>
 
   

   
* Public Foo (bar bar) {
 
   

   
* This.bar = Objects.requirenonnull (bar);
 
   

   
* }
 
   

   
* </pre></blockquote>
 
   

   
*
 
   

   
* @param obj The object reference to check for nullity
 
   

   
* @param <T> The type of the reference
 
   

   
* @return {@code obj} if not {@code null}
 
   

   
* @throws nullpointerexception If {@code obj} is {@code null}
 
   

   
*/
 
   

   
  Public static <T> t requirenonnull(t obj) {
 
   

   
 if (obj = = null)
 
   

   
 Throw New NullPointerException ();
 
   

   
 return obj;
 
   

   
}
 
  

Self-initiative throw new NullPointerException () This situation the JVM is not the case, the user code is actively assigned, the user wants how to engage in how to do.

Interesting question: In the Java language, use only the Java language and the functionality of the standard library without relying on a third-party library, checking to see if a reference to obj is null and throwing the NPE in null.
Answer: Obj.getclass (). This is because GetClass () is a method on the Java.lang.Object class and therefore can be used regardless of the reference type. This is the shortest at the Java source level and at the Java bytecode level.
This is, of course, a wicked trick, but it is not uncommon in OPENJDK's standard library implementations. Everyone... It's better to use Objects.requirenonnull ().

Return null is mainly a trouble, where the call to it, all to think about, is not to judge if (XXX = = null), so that the code is not elegant.

On the language level, returning null has no problem and everyone agrees.
In engineering practice, is returning null a bad habit? I don't think so. My point is that all method invocations, whether they are internal class methods for their own projects or methods in a third-party package, should be suspected of having the possibility of returning null pointers unless explicitly stated in Java doc that they will not return null. There is nothing wrong with one more judgment, and it can greatly increase the robustness of the code. On the other hand, the writer of the method should also carefully maintain the Java DOC, if it returns a null pointer, it should explain the reason and semantics, so that the caller has a chapter to follow.

In Java, return null is safe, why?