Design and refactoring of exception handling learn a

Two metrics for the program:
---> Correctness (Programmer's code can achieve the correct function)
---> Robustness (when an unexpected condition "parameter error, power outage, etc.", the program can safely and accurately exit, will not produce unexpected results)

Villains that affect program robustness
---> Defects (physical defects [hardware], Code defects [Code vulnerabilities])
---> Errors (Code bugs)
---> Failure (method cannot achieve the purpose)
---> Exceptions (bad run parameters or bad run environment)

The design of exception handling mechanism in object-oriented language is a factor to consider
---> Expression: How to express an exception?
---> Disclaimer: Is it necessary to declare an exception that is passed out?
---> Notifications: How do I generate an exception instance?
---> Pass: How do I pass an exception?
---> Architecture: What program blocks can an exception handler bind to?
---> FIX: How do I find an exception handler that can handle it for an exception?
---> Continue: After the exception occurs, how does the program's control process proceed?
---> Cleanup: How do I get the program to clean up resources to maintain its normal status, regardless of whether or not an exception occurs?
---> Reliability check: What kind of check does the program language provide because of the problem caused by the exception handling mechanism?
---> Concurrency: How much exception handling is supported by the program language for parallel handlers?


One: Expression
The "1" program language has the following three ways of expressing exceptions:
==> symbol: An exception is expressed by a string or an integer. Prevents degradation of the system performance due to phase representation errors.
==> Data Objects: Use objects to represent and store error messages, which is the most common way to express an exception. The exception object basically has no behavior method, but simply uses the object form for the data use
==> Complete object: In addition to using objects to represent and store error messages, and even how to produce an exception instance, passing exceptions, the process of program control after an exception occurs, are all defined in the exception class.

Two: statement
The "1" function passes the exception outward, whether it needs to be declared above the function interface. Has the following several
==> Mandatory: All exceptions that need to be passed out must be declared on the function interface. The "Check exception" for Java takes a mandatory declaration. Example:
Package com.yeepay.sxf.exception;
Import java.io.IOException;
/**
* Interface
* Exception: Internal exception error (power outage, insufficient resources, etc., the programmer can not handle through the code)
* External Exception exception (programmers can circumvent these exceptions by code)
*
* Exception exceptions are classified as runtime exceptions (non-check exceptions)
* Compile-time exceptions (check for exceptions)
* @author SXF
*
*/
Public interface Mybookservice {
/**
* All exceptions that need to be passed to the outer layer must be declared on the interface
* Methods that call this implementation method need to handle the exception (or throw or catch)
* @return
* @throws IOException
*/
Public String GetBook () throws IOException;
}
==> selectivity: The sound does not declare all can, for example, Java "Non-check exception" can not be declared on the interface method, even if the declaration is not wrong.
/**
* Non-check exceptions, can be declared in the interface method, or not.
* @throws IOException
*/
public static void test01 () {
throw new IllegalArgumentException ();
}

==> not supported: Declaring an exception on an interface is not supported at all. For example, in the C # language, there are no keywords to support exception declarations. Developers can only comment on the name of what exception the method throws.
==> Hybrid: Supports more than one of the above declaration methods. Broadly speaking, Java is a hybrid approach to whether exceptions need to be declared. Because only the "check exception" is mandatory to declare. The "Non-check exception" option is the choice of the Declaration method.

Three: Notice
"1" This action of passing an exception instance to the exception receiver is called sending a notification. From the perspective of sending notifications, the way the exception is generated can be divided into the following two forms.
==> Synchronization Exception: exception resulting from failure of the instruction or function being invoked in the program
==> Async Exception: An exception that is actively thrown by the execution Environment (JVM) is not directly related to the instruction or function currently executed by the program. For example, an exception that is thrown by an execution environment that detects an internal error or insufficient memory, such as Java OutOfMemoryError, is an asynchronous exception.
Most of the exception handling designs in "2" are talking about how to handle synchronization exceptions. Therefore, when an asynchronous exception occurs, it usually indicates that the execution environment has produced a serious error. At this point the best way is to end the program execution, to avoid a mistake again. Whether the interface of the software component can be passed out from the exception. You can also divide the exception into two types
==> Internal exception: An exception generated within a software component, the main purpose of which is to jump program execution control to an internally defined exception handler. An internal exception cannot be passed outside of the software build. The Catch-live exception.
==> External exception: an exception that cannot be handled within a method inside a software component that needs to be passed externally. Throws out of the exception.

IV: Delivery
"1" now discusses the problem of abnormal delivery. For example, the A function calls the B function, which produces an exception inside the B function, but the exception is not caught by the B function, the exception may be passed to the a function.
There are two ways of passing exceptions
==> Explicit: (1) Declare an exception on the interface (check exception or non-check exception) (2) method internally catch the exception of the calling method and throw it into another exception.
/**
* Non-check exceptions, can be declared in the interface method, or not.
* @throws IOException
*/
public static void test01 () {
throw new IllegalArgumentException ();
}

/**
* When the exception is caught, processed, converted to the client to recognize the exception, the outward throw
* @throws Exception
*/
public static void test02 () throws exception{
try {
TEST01 ();
} catch (IllegalArgumentException e) {
E.printstacktrace ();
throw new Exception ();
}

==> implicit: Also known as "automatic delivery mode". The method of receiving the exception, if you do not want to handle the exception, by default, the exception will be passed directly outside, do not need to deliberately specify to throw this unhandled exception out. Java's "non-checking exception" is an implicit pass-through exception.


V: Architecture
The schema for exception handling in "1" Java is try{}catch{}finaly{} statements. There is no explanation here.
VI: Resolve processing
"1" exception handling is also called program binding, to explore how to find an exception handler procedure. There are several ways to find the handler.
==> static Range: From the code structure, you know what needs to be handled. This is the catch exception, which is handled in the catch block.
==> Dynamic range: Multiple catch blocks, each catch block catches an exception that is not the same. The corresponding exception, which is handled by the program in the corresponding Catch block
==> semi-dynamic range: purely static or dynamic range determines how to find.
==> Stack unwinding: When the program executes, the order of the function calls forms a chain of calls, and the call chain is usually saved in a stack by the execution environment. The stack unwinding means to look out the stack one layer at a level until a suitable exception handler is found.
==> Stack cutting: Another way to find out is to put the exception handler in a list. When an exception occurs, go to the list and find out if there is an appropriate exception handler.
Seven: Continue
"1" Exception processing is also known as the Anomaly model, the specification is when the exception handler is completed after the return control, the program's execution process. Common anomaly models include the following three types of
==> terminates the model: the point at which the exception occurred, not marked. After the block code that is catch is executed, the execution of the code begins after the catch block, not after the point at which the exception occurred. So the continuation of Java, for the terminating model.
==> Recovery model: After the exception handler is executed, the line of instructions that originally occurred will continue. Visual Basic supports this model. After the exception has been processed, you can use the Resume or Resume Next command to return the process control to the line where the exception occurred or to the next line of the program.
==> Retry Model: It is the combination of the termination model and the recovery model.
Eight: Clean up
"1" regardless of whether an exception occurs, the components of a software should be kept in the correct state. The cleanup action is included after the error has occurred, allowing the system to revert to an acceptable consistency state or to release resources to avoid resource exhaustion.
==> Display Delivery: The system calls the resource cleanup code before the exception is passed out.
==> specific constructs: Use a specific construct to ensure that the program code for resource cleanup is executed regardless of whether an exception occurs. The code for cleanup resources is placed in the finally block of Java.
==> Automatic cleanup: The system automatically cleans up all resources. Programming does not need to be concerned with the issue of resource release at all. There seems to be no mainstream programming language to do this at the moment. Java's try-with-resources and C # using, barely a closer to automatic cleanup practice
Nine: Reliability check
"1" Exception handling is also a program design. Therefore, errors may occur because of the exception handling mechanism of the program language. Reliability check, divided into the following two kinds
==> static check: is the compiler check. Check your exception-handling code to see if it conforms to the language syntax.
==> dynamic Check: By the programmer's own ability, the control of the code. To perform the appropriate checks.
Ten: Concurrency.
"1" parallelism or concurrency is a relatively high-end project in a programming language. If exception handling takes into account concurrent processing, it allows several exceptions to occur at the same time. The exception handling mechanism should also consider how to deal with these simultaneous anomalies. Program language pairs and parallel processing exceptions, can be divided into the following three kinds of
==> not supported: Old programming language C + +, no support for built-in parallel processing, not to mention exception handling mechanism in parallel processing programs
==> Limited support: Can be in the multi-threaded program to throw exceptions, but the exception handler parsing is inseparable from the programmer's planning, the system does not support "inseparable action"
==> full support: For parallel processing of the program's exception handling has the most complete support (ideal), the program language can be developed those functions are inseparable actions, when the execution fails, the exception handling mechanism to ensure that these indivisible action state integrity. This is basically supported as long as the exception condition is related to the parallel handler feature.

Design and refactoring of exception handling learn a