Null Pointer exception Summary

1: nullpointerexception is derived from runtimeexception and is a running-level exception. This means that it may be thrown during running, and you need to check whether such a running level exception will interrupt your business logic.

2: The NULL pointer exception occurs when the object is null, but the method of referencing this object. For example, string S = NULL; // The object S is null (null) int length = S. Length (); // a null pointer exception occurs.

3: a variable is null and has only its name, no real value content, and no memory is allocated. When you want to get its length, the nullpointexception will occur when you operate on it, therefore, it is best to allocate memory space to a variable and assign values to it.

4: for example, if the variable is null and you do not determine it, You can directly use it to see nullpointexception. WriteProgramIt should be more rigorous and avoided as much as possible. For example, when comparing the variable with a value, you must first handle the exception, for example, if (STR = NULL) {system. out. println ("the character is null! ");} Of course, you can also write this value in front for comparison, for example, to determine whether the value of a string instance S is equal to" A ", do not write it as S. equals ("A"), so it is easy to throw nullpointerexception and write it as "". equals (s) can avoid this problem. However, it is better to empty the variable before performing the operation.

5: avoid returning null as much as possible. The return value of the method should not be defined as a general type, but an array. In this way, if you want to return NULL, an array without elements will be returned. To avoid many unnecessary nullpointerexception, it is a good choice to use nullobject to return NULL instead.

6: nullpointerexception. In another way, it may be a benefit or not. It can be said that nullpointerexception itself is also part of the Java security mechanism. Anyone who has experience writing C and C ++ on Unix may know what problems a null pointer may cause: program crashes often. Java makes improvements at this point. In order to ensure the program is strong, Java always checks object references. Therefore, the Null Pointer Error in C/C ++ is no longer exposed, but a running-level exception-"nullpointerexception ". From this point on, it is a benefit of Java.
Josha Bloch mentioned in objective Java that the function returns an array. If no return value exists, the zero-length array is first returned instead of null. However, it is a good choice to use nullobject to return NULL instead. The Return Method of the array can also return NULL, because the array has been developed into a complete object in Java. If so, invoker will inevitably check nullpointerexception. Initial values are not what you want to decide. In many cases, you cannot determine the initial value of an object. So this habit is not necessarily a good habit. For example, you think:
String STR = ""; this is reasonable, but why not string STR = "? In some cases, "" is a reasonable initial value. The key is to establish a contract for the publish method. If you use a third-party method, you need to read its javadoc to see if it will return a null object? Whether to throw a checkedexception and whether to throw a running level exception. If it is your own publish method, you need to describe the contract of your method in your javadoc: What conditions are met before this method can be called, what will be returned after the call? Will return/When will return NULL? Whether to throw an exception. When implementing the publish method, the entry parameter check is also critical, because the caller's behavior is unexpected.
In fact, exception handling is a very interesting topic, not just nullpointerexception. For example, there is an example in DBC: You need to open a file to read, which may be c: \ data.txt, but the file is not found. Isn't it an exception? If you need to open another file, for example, C: \ Boot. ini, the file is not found. Isn't it an exception? The first case is not "exception", because c: \ data.txt is not found and should be expected. The file may or may not exist, you need to handle this by yourself. The second case is indeed an exception, because under normal circumstances, c: \ Boot. ini should be expected to exist. If this file is lost during running, it is a running level exception. There are also examples in JDK, such as fileinputstream,
Bufferreader and stringtokenizer are different when processing arrives at the end. <4. Why is resultset inappropriate as the processing result?> Coupling irrelevant things together. The result set logic of the JDBC query is coupled with the logic of the data aggregation you need. In this way, the abstract cannot be implemented. Now we are randomly retrieving results from the database, so you use the resultset. If the requirement changes, you need to retrieve the results from the text file source. What is your resultset interface? Therefore, it is better to abstract the interfaces for data acquisition, and implement different interfaces. "Single responsibility" is critical, so you do not need to be coupled without coupling.

7: When I write a program, string uri = getsavepath () + getuploadfilename (); system. out. println (URI + "123345"); // string linkname = getuploadfilename (); string update = "Update usertable set uri = '? ', Linkname = '? ', Linkid = '? 'Where username = "+" '"+ username + "'";
Databaseoperate DBO = new databaseoperate (); preparedstatement PS = DBO. getconnection1 (). preparestatement (update); PS. setstring (1, Uri); // This row returns a null pointer exception? PS. setstring (2, linkname); PS. setint (3, I ++); ps.exe cuteupdate (); is it added? To automatically give the variable a value '? '
Changed to a character constant...