Definition, use, and handling of exceptions

Here I will write down my understanding of the exception mechanism in Java. Some knowledge comes from books and practices, while others are my personal opinions, if you are not interested, please refer to the following discussion:-) 0-Exception Handling ==== Exception Handling should be concentrated at a certain layer as much as possible, and sufficient context information should be available for handling exceptions, know how to handle exceptions. For Exception Handling, you can master the preceding simple principles in the Client Code. This is not the focus, but the definition and throw (use) of exceptions ). 1-before and after an exception, when will an exception occur in the status of each related part? Why? When an exception occurs, what status will each related object (data) be in? (The so-called related object is the object of each layer passing through the method call path, from the layer of the new exception to the layer of the catch exception) or you cannot predict the status of these objects or data? Can the program continue running? If the relevant objects and data are in a predictable and stable State after an exception occurs and the program can continue running, do you want to send a message to the user? What information is prompted to the user? Is the exception caused by user operation errors? Is there a way for the user to successfully avoid this exception by calling the same function through correction operations? If the exception is not caused by user operations, will the exception always occur when the program continues to run and the user performs the same operation? =====-> If an exception occurs, you cannot predict the status of the relevant object or data, or you expect the related object or data to be in an unstable (or illegal) State. For example, the state of the object does not comply with its own constraints (constraints ), if you perform further operations on the object, unexpected behavior will occur ............ So this exception cannot be recovered, which should cause the program to crash and exit. In this case, friendly information is displayed to the user. For example, "to prevent more damage to the data, the program will stop running ..................", Then try your best to end the program safely. This exception should be designed as an unchecked exception, which is generally extends RuntimeException or its subtype. -> If an exception is caused by illegal user input, it should be avoided in the program. That is, illegal user input should be checked out before the exception is caused, then, instead of calling the function, the system gives the appropriate information to the user. If the legality of the checked input is very expensive, or the legality cannot be checked before the function is called: One possibility is that the function is designed incorrectly; if there is no problem, it means that you cannot check the function before calling the function, or the check is too expensive, you can only try-catch. In this case, it is necessary to determine the status of each layer of the entire call path in the event of an exception, if you want to ensure that the program continues to run after an exception occurs, each layer should be in the status before the original call, just as the call did not happen. Then you can feel free to give the user a prompt and try again. (The validity of the function cannot be checked before it is called. This situation is probably mostly found in the multi-threaded environment, when an interface guarantees thread security externally.) The exception here is, it can be designed as a checked exception or a non-check exception. This is a trade-off in design. If the call path is long and you do not want to pollute the signatures of each layer of methods (throws), it is designed as a non-check exception. The core issue here is to indicate the status after an exception occurs. 2-before a method is called, is there a way to check in advance whether the call is always abnormal? =====-> Is there a way to check whether an exception occurs or not in this call? If there is a way to check, -- provide the method for this check. In this way, the user code will not be forced to use try-catch for process control. Instead, you can call this check method first and decide whether to call the function method itself. It should be noted that such a design will make the interface lose the possibility of "ensuring thread security", that is, the interface designed in this way cannot guarantee thread security to user code, -- because there is a logical relationship between the two method calls. Someone once asked "How To Get A thread-safe List ?", -- There is no such thing as "thread-safe List", because the size () method and the get (index) method will throw the logical relationship between IndexOutOfBoundsException, the interface itself cannot provide atomic protection for these two related calls. An exception that can be checked with a prior check should be defined as a non-check exception. Otherwise, try-catch must be written after the user code calls the check method, in the catch that should not occur theoretically, what do you want the user code to write? 3-Now let's take a look at what kind of exceptions can be designed as check exceptions. ===== If an exception can be defined as a check exception, it must meet the following conditions:-exceptions cannot be predicted before the method is called-exceptions occur, related objects and data will remain in a stable state, that is, after an exception is caught, the program can continue to run (confidently)-exceptions are so important, so that all the method code in the call path should be aware of its existence, and the exception such as writing throws into their method signature can be defined as a check exception. Note: You can:-) -- You can never be wrong to define an exception unchecked. For any exception, You can define it as a non-check exception and it will never be wrong. (But note that the exception should be written into the Java DOC, that is, the method protocol.) In fact, the necessity of "Checking exceptions" itself is controversial. For a programmer who knows how to handle exceptions, they will also carefully handle and design non-checking exceptions. For a programmer who does not know how to handle exceptions, the mechanism of "Check exceptions" can only cause a large amount of abuse, and a large number of interface signatures are contaminated. If you find that you frequently catch a check exception in the code and then throw a non-check exception by converting the code, most of the design issues with this check exception. (Is java. io. IOException shot ?)