Owl's Late Night Translation: Interesting Talk about Java Exception

Preface

Java exception class (Exception) is a set of classes used to handle abnormal program behavior. In this article, I will introduce how to use Java exception classes and how to design the Java exception system in the program. The Exception class is a very important part of the Java system, and every programmer must be familiar with and master it.

The amount of information carried by Java exceptions is beyond your imagination

The structure design of Java Exception itself can provide developers with a lot of information (if developers can use this structure appropriately). The structure of Exception is shown in the figure below:

Throwable is the parent class of the entire abnormal structure. It has two subclasses, namely Error and Exception

Java Error

Error class represents abnormal scenes. Once the Error abnormality occurs, the entire application may crash.

Java Exception

Exception and Error are different. When this type of exception occurs, the program can try to recover and continue to run. There are two types of Exception: Runtime Exception and Not Runtime Exception:

Non-runtime exceptions also become checked exceptions. This type of exception is very similar to Error exceptions. The difference between the two is that the program throws a checked exception with a higher probability of returning to normal.

Checked and Unchecked exceptions

The Checked exception forces the developer to handle it in the program or throw it again. If the checked exception is rethrown, you need to declare the exception in the method with throws syntax. In contrast, Unchecked exceptions do not require special handling. This design structure means that unchecked exceptions that are not actively handled will be thrown to the root class.

How to handle exceptions in JAVA

There are two ways to handle exceptions in Java: handle them in the current method or rethrow them. You may need a parent exception handler, or perform some other specific logic, such as retrying.

As shown above, we can divide exceptions into three categories: Checked, Runtime and Error. They are thrown in different scenarios, representing the extent to which the program can be restored. The most optimistic is the Checked exception. The Runtime exception is relatively less likely to be recoverable. The worst is the Error type exception.

After understanding the type of exception, we can try to answer the following questions:

• How bad is the current situation of the program? What is the cause of the problem?
• How to fix the problem?
• Do I need to restart the JVM?
• Need to rewrite the code?

Familiarity with the exception means that we can speculate where the program has a problem and try to fix it. The following chapters will show several classic abnormal scenarios and analyze the reasons (assuming that the program has passed the compilation self-test phase)

<!-- more -->

Analyze Error

Let's start with the most serious Error exception. The most common Error exception is shown in the following figure:

In most cases, you only need to modify the JVM configuration or add missing dependencies. Of course, there are also a small number of scenarios where the code needs to be optimized.

Analyze Checked exception

For Checked exceptions, it usually means that the program may recover from this exception in some way, such as retrying. Several more classic Checked exceptions will be given below, some of which may be the parent of other exceptions, and the correlation between these exceptions will be analyzed here.

So, what does this table show? If you observe carefully, you will find that in most cases there is no need to modify the code, or even to restart the application.

Analyze Runtime exceptions

Runtime exception is the most common exception. Generally speaking, Checked and Error exceptions do not require code changes, but Runtime exceptions usually mean that the code must be modified to fix the problem. The following table shows the most common Runtime exceptions:

It can be seen how much damage the Runtime exception will bring to the program. It is the culprit that caused code repairs, increased programmer pressure and business losses.

Code pollution caused by Checked exception

According to the definition of Checked exception, developers should throw every recoverable problem through Checked exception. But this also means that the exception needs to be mandatory in the method definition, and the caller must add three or four additional lines of try-catch logic to handle the exception. If the program is full of such code fragments, it will greatly affect the readability of the code. Therefore, I recommend using RuntimeException for exception management. Even when designing an API, you can also define Runtime exceptions in the method and add annotations to assist the caller in understanding. The API caller can decide whether to handle the exception or continue to throw it upwards.

Original link: dzone.com/articles/java-exceptions-1