| Java provides two main types of exceptions : runtime exceptions and checked exceptions . Checked exceptions are the IO exceptions we often encounter , as well as SQL exceptions. For this kind of exception, the JAVA compiler enforces that we must catch these exceptions that appear . Therefore, in the face of this kind of exception, whether we like it or not, we can only write a lot of catch blocks to deal with possible exceptions. But another kind of exception: runtime exception , also known as runtime exception, we can not handle it. When such an exception occurs, it is always taken over by the virtual machine. For example: we have never dealt with NullPointerException exception, it is a runtime exception, and this exception is one of the most common exceptions. I have never thought about how the system will work when a runtime exception occurs. Recently, when troubleshooting a module, I accidentally discovered how the system handles runtime exceptions. After a runtime exception occurs, the system will throw the exception to the upper layer until it encounters the processing code. If there is no processing block, go to the top layer, if it is multi-threaded, it will be thrown by Thread.run() , and if it is single-threaded, it will be thrown by main() . After throwing, if it is a thread, the thread also exits. If the exception is thrown by the main program, then the entire program will exit. The runtime exception is
Subclasses of Exception , which also have the characteristics of general exceptions, can be handled by Catch blocks. But often we don't deal with him. That is to say, if you do not handle the runtime exception, then after the runtime exception occurs, either the thread is terminated, or the main program is terminated. If the program exits just as you expected, then everything is OK . But the problem I encountered in the project recently was precisely because the runtime exception was not handled, and the program crashed after running for a short period of time. The thing is, because I am not very good at multi-threaded concurrent processing when writing the program, I also wrote a module as a single-threaded, and used it to process a data queue in a loop. But I didn't expect some data in the queue to be different from the expected format. When processing such data, the program throws a runtime exception. Since the exception is not handled, the exception is thrown to Thread.run() . Finally, the processing thread must be terminated, and the data in the queue will no longer be processed by the program. This result is obviously not what I want. There is abnormal data in the queue. The normal processing should be to discard the abnormal data and record the log. It should not affect the processing of normal data due to abnormal data. So in the end, I added a catch processing to the loop processing module of the program to catch all exceptions and never let this processing thread exit. You must know that all my data still depends on him to handle it ( ^_^ ) . This may be a good application in this scenario, but it doesn't mean you should do it in all scenarios. If you encounter some errors in other scenarios, it is better to exit the program, then you can ignore the runtime exception, or explicitly control the program to exit by handling the exception. Knowing how the virtual machine handles runtime exceptions, and further understanding
Sping对Hibernate的封装了。由于Hibernate是和数据库打交道，所以总是要抛出一些乱七八糟的checked异常，平时我们根本不想catch这些异常。因为这些异常总是把代码弄的乱乱的，搞的到处都是try{} catch(){}块，并且常常加了catch块，也并不能把程序从异常中恢复过来（异常处理的目标之一就是为了把程序从异常中恢复出来）。为了通过编译器的检查，程序员被迫加上了catch块，往往这些catch并没有发挥他应有的作用，反而带来了很大的不便。所以Spring对Hibernate封装时就把Hibernate的异常进行了封装，全部封装成运行时异常了。也就是Spring来扑捉Hibernate抛出的异常，然后Spring把异常转换成Spring自己定义的运行时异常再抛出。这样我们在编码时使用Spring来调用Hibernate时，可以不用catch块来处理一些不必要的异常。当然你确实要是想处理，也可以通过添加cathc块去处理异常。不过这个时候，你的Catch就要扑捉运行时异常了，而不是一般的checked异常了。 |