NullPointerException encountered in the project is divided into two situations:
1. Reference the empty object, that is, call the method of the empty object or refer to the properties of the empty object.
2. Assign the encapsulation classes of the basic types in 8 to the corresponding basic classes.
1. We need to make non-null judgments on the objects returned by other people’s interfaces, because we don’t know whether the objects obtained will be empty. For Collection Map, I usually call CollectionUtils MapUtils. For the returned String object, I will call StringUtils.isNotEmpty( ) to perform non-empty judgment. Among them, isNotEmpty not only judges NULL but also judges empty sets and empty strings. For example, query results from data. Pricing URL returned in workflow
2. For the objects you create, you should pay attention to what operations the object performs, and whether the object will be empty in the middle. If possible, add a non-null judgment, especially for collection operations, it is easy to report a null pointer! ! ! So every time I operate a collection, I will be very careful.
3. Be very careful about the field objects in the foreground, because these objects are created by the framework. If I do not enter a value in the text box in the foreground, although the backend will get an empty string when submitting, the probability of NullPointerException is very high.
4. For String operations, try to use the StringUtils class of apache. Compared with String, this is very safe. For collection operations, use apache's CollectionUtils and MapUtils. Compared with apache tool classes, the execution efficiency is also very high, such as StringUtils.split();
Some people say that too much judgment will affect performance. I personally think that the performance sacrifice here is negligible compared with the security of the system.