Java provides two main types of exceptions: runtime exception and checked exception. The checked exception is the IO exception that we often encounter and the SQL exception. . For this exception, the JAVA compiler requires that we must . Therefore, in the face of such exceptions, whether or not we are willing You can only write a large number of catch blocks on your own to handle possible exceptions.
But there is another exception: runtime exception, also known as a runtime exception, which we can not handle . When such an exception occurs, it is always taken over by the virtual machine. For example, we have never been NullPointerException handled It is a running exception, and this exception is one of the most common exceptions. I have never thought about how the system works when an exception occurs. Recently, when a module troubleshooting error occurred, it accidentally discovered how the system handles runtime exceptions. . When an exception occurs during running, the system keeps throwing the exception to the upper layer and keeps encountering code processing. . If there is no processing block, to the top layer, if it is a multi-Thread, the Thread . Run () Throw. If it is a single thread, it is thrown by main. After throw If it is a thread, the thread will exit. If the exception is thrown by the main program Then the entire program exits. The Exception is a child of Exception. Class, which also has the characteristics of general exceptions and can be processed by Catch blocks. . But we often don't handle it. That is to say, if you do not handle runtime exceptions , Either the thread is terminated or the main program is terminated. If the exit of the program happens to be your expectation Then everything is OK. But recently I encountered a problem in the project, because I did not handle runtime exceptions. As a result, the program becomes effective after a short period of time. This is the case. When I write a program, I write a module A single thread that processes a data queue cyclically. But I didn't expect the data in the queue to be Some are different from the expected format. When processing such data, the program throws the runtime exception. . Because the exception is not processed, the exception is thrown to the Thread . Run (). The processing thread must have been terminated, and the data in the queue is also There will be no more programs to process. This result is obviously not what I want Exception data in the queue. The normal processing should be to discard the exception data. And then record the log. Normal data processing should not be affected due to abnormal data Ah. So at last, I added a catch in the loop processing module of the program. , To catch all exceptions, never let this processing thread exit, you need to know all my data It depends on him to handle it (^_^ ). In this scenario, such processing may be a good application, but it does not mean that You should all do this. If you encounter some errors in other scenarios If you exit the program, you can ignore the running exception. Or exit through an explicit control program for exception handling. Understand how the Virtual Machine handles runtime exceptions, and further understand Ibatis is encapsulated. Since Hibernate communicates with databases , So always throw some messy checked exceptions We do not want to catch these exceptions at all. Because these exceptions always get the code The catch () {} blocks are everywhere, and catch blocks are often added. And cannot be recovered from the exception (one of the goals of exception handling is The program recovers from the exception ). To pass the compiler check, the programmer is forced to add Catch Block, which often does not play its due role But it causes great inconvenience. So Spring seals Hibernate During installation, Hibernate exceptions are encapsulated as runtime exceptions. Always. That is, Spring is used to catch exceptions thrown by Hibernate. Then, Spring converts the exception to the runtime exception defined by Spring itself. Then throw. In this way, we use Spring to call Hibernat During encoding. You do not need catch blocks to handle unnecessary exceptions. . Of course, if you really want to handle the exception, you can also add a cathc block to handle the exception. . However, at this time, your Catch will Catch exceptions during running. Instead of the general checked exception. The above point of view is just a reference of experience. If there is something wrong, please advise (email: flyfoxs + blog0528@gmail.com ). Runtime exception and checked exception may not be easy to understand. For more information, see the following documents. References: http://www.pconline.com.cn /Pcjob/process/sun/experience /0511/719750 .html
