Deep analysis of Java exceptions

Java exceptions are divided into two categories: checked exceptions and runtime exceptions. Checked exceptions are exceptions that can be handled in the compilation stage.

Difference and relationship between checked exception and runtime exception

Common exception class

List several common runtime exceptions:

List several non runtime exceptions (checked exceptions):

Error error

Error error generally refers to problems related to virtual machine, such as system crash, virtual machine error, dynamic link failure, etc. this error cannot be recovered or captured, which will lead to application interruption. Generally, the application cannot handle these errors, so you should not try to catch the error object in the program. The throws error object is also not required for method definition.

Use of checked exceptions

As mentioned earlier, checked must be processed explicitly, or an error will be reported during compilation, such as declaring a file input stream:

This code compilation will report an error

Therefore, it must be handled explicitly. There are generally two ways to handle checked exceptions:

If you know how to handle it, you'd better use try... Catch Block processing:

If you don't know how to handle it, throw it in the method and be handled by the caller at the next higher level:

Use throw to throw your own exception

Sometimes, according to business needs, we throw exceptions in the program. For example, if the read file content is empty, we think it is an exception. At this time, we can use throw to actively throw an exception and catch it:

If throw throws a runtime exception, the program can catch it with try... Catch... Or ignore it.

Exception chain handling

In real enterprise applications, we often don't expose the underlying exceptions to the upper applications, such as SQL exceptions to the user interface. First, it is not helpful for users to see SQL exceptions. Second, it is unsafe for malicious users to expose underlying exceptions.

So how to shield the underlying exceptions? The usual approach is: the program first catches the original exception, and then throws a new business exception. The new business exception contains the prompt information to the user. This processing method becomes exception translation. The following shows how a user creation program can mask the underlying exceptions:

It can be seen that the program hides the original exception and only provides the necessary exception prompt information upward, which can ensure that the underlying exception will not extend to the presentation layer, which fully conforms to the object encapsulation principle.

This method catches an exception, throws another exception, and saves the original exception information. It is a typical chain processing, which is called the responsibility chain pattern in the design pattern.

Some suggestions on using exceptions

We use exceptions to achieve several goals:

In view of these objectives, we should:

1. Don't overuse and rely on it: exceptions are convenient, but don't use exception handling for normal logical processing, such as