[One question per day] Exception Handling Mechanism and best practices

This is a matter of benevolence, wisdom, and wisdom. The best practices in everyone's mind are not necessarily the same. But if you have to have an idea, this is the key. If you haven't even thought about it, it's not a good idea.

Many advanced Languages provide Exception Handling, such as Java, Python, and Ruby. For example, C does not provide exception mechanisms. Recently, golang, there is no common try-catch exception mechanism.

Is the exception mechanism necessary? Obviously not, because we can usually use multiple return values to solve the problem. If the language itself does not support multiple return values, the exception mechanism is necessary. Otherwise, it will be really painful to write this language, do you think so? :)

An exception occurs. The program execution process is abnormal. Let's take a class inheritance relationship in Java as an example:

Exceptions can be divided into two types:
1. There is no way to recover, the error in the red part, this exception occurs, the program can only crash. For example, outofmemoryerror indicates that the system memory is insufficient and the program obviously cannot run and must crash.
2. You can try to recover the green part of the exception. This usually does not cause program crash, but I am talking about the normal process. If it is not handled properly, the program will crash.

For the first case, we cannot handle it. It is an uncontrollable factor. The usual practice is to monitor it in advance. For example, if the remaining memory of the system is less than 10%, the O & M personnel must have a deep feeling about it :)

In the second case, we must do our best to deal with it, because our service should pursue the highest possible stability, with five or six SLAs, so the program immediately crash when throwing an exception, it is not suitable

Next we will focus on the green part of exceptions. Exception Handling mechanisms in most languages are similar, such as C #, Python, and Ruby. if an exception is thrown, the upper-layer code can be captured or not captured, the language designer thinks this is okay. Java is further divided into checked exception and unchecked exception.

A) Checked exception is explicitly declared when the method is defined, and the upper-Layer Code should also be explicitly captured, which will be forcibly checked during the compilation phase.
B) unchecked exception, also known as runtime exception, does not need to be explicitly declared during method definition or force upper-layer code to be explicitly captured. Once an exception is thrown, JVM will search for catch blocks along the method call stack layer by layer. If no catch block is found, the program crash

What are the application scenarios of these two exceptions? The following is my personal opinion for your reference only:

1. runtime exception is only used to handle bad codes. These are all codes that programmers should handle in advance but forget to handle. For example, nullpointerexception should be used to determine whether the variable is null in the upper-Layer Code, if you forget to judge, the lower-level code can only use the runtimeexception nullpointerexception to return the color. For example, arrayindexoutofboundsexception and illegalargumentexception. Do you have any feelings?

2. Although runtimeexception is a programmer's mistake, it is still necessary to handle it in order to avoid program crash. Therefore, we usually catch all exceptions at the top of the method call stack, and then print the log, send an alarm email to engineers to facilitate future bugfix and other

3. Checked exception usually requires the programmer to try to recover, such as filenotfoundexception and eofexception. Checked exception Transmits some information to the code at the upper layer to suit the upper-Layer Code

4. For example, if we encounter a Connection Reset exception when dealing with databases, which exception should be encapsulated and returned? Obviously, this is not caused by bad encoding. Therefore, checked exception is used. The upper-Layer Code must be explicitly caught. If connectionresetexception is found, reconnect to the database.

5. When a user logs on, someone encapsulates usernotfoundexception and passworderrorexception. Do you think this is reasonable? I personally think this can be used. For example, if you write a login method, a user logon failure may be caused by multiple reasons. To send this information to the upper-Layer Code, in a language without multiple return values, multiple exceptions are allowed

6. JDK provides a filenotfoundexception exception to indicate that the file does not exist. Do you think this is reasonable? The author's point of view is as follows: if you want to write a method called fileexists that specifically determines whether a file exists, you do not need to define an exception and simply return a value of the bool type, if you find that a file does not exist in the method of reading and writing a file, you can throw an exception because there cannot be multiple return values, because the method parameters and returned values of the file read/write operations are the same as the number of bytes, the byte array, and so on, there is no way to pass this information to the file, so you can only use an exception.

7. If you can use the IF-else branch structure to describe the logic, do not use exceptions. Although try-catch looks like it can be used as a branch structure, try-catch is inefficient and not properly encoded, benefits

It seems that the text writing is still not good. I hope it will help you with reading more articles :)
This article is from the Public Account: it_mianshiti. It is relatively weak for a person to sort out the interview questions every day. Please submit the article :)

[One question per day] Exception Handling Mechanism and best practices