A unified exception handling scheme for JS Building UI (iii)

The author has analyzed how to realize JS's responsibility chain exception processing method, through promise this asynchronous model, we can realize the responsibility chain pattern in two cases of synchronous method and asynchronous method. With these weapons, we can begin to design a unified exception handling scheme for the UI.

1. Unified Exception Handling Scheme

The so-called Unified exception processing scheme, in fact, refers to those who can not be processed at the bottom, a layer of thrown into the boundary class exception, in the boundary class according to the different types of exceptions, to make different processing strategies. In order to be able to judge the type of exception in the boundary class, we need to define the common exception type and then wrap the original exception as the type of exception defined inside these systems. Therefore, the requirements of the whole unified processing scheme are as follows:

1. Exception handling must be a chain of responsibility pattern that eventually throws the underlying unhandled exception onto the boundary class.
2. You need to wrap the system exception on the original exception and encapsulate it as a system that we specify.
3. The system exception encapsulation process needs the business code decoupling, facilitates later expands to it.
4. The uniform exception handling in boundary classes can be different from the different system exceptions.
5. system exceptions and processing policies can be increased.
6. The system exception must contain the wrong stack call information, which makes it easy to find errors when debugging.

This unified processing of exceptions, we are often used in server-side development, the client often do not need to implement this complex exception handling scheme. But as the front and rear stations are fully decoupled, especially for spa applications, however, the frontend is now more complex. While the complexity of the system, the probability of anomalies and the difficulty of exception processing is also increasing, so uniform exception handling is also suitable for the client, that is, our UI page.

2. Unified UI Exception handling scheme

If the back-end exception handling core is logging, then the UI's exception handling core is to respond to the user. Different errors to the user's response should be not the same, we need to analyze the common anomalies and design a processing strategy for them, which is the core of the UI exception handling scheme.

For clients (that is, the UI), it is usually designed with the MVC pattern, or it is the MVVM that has recently become popular. Either way, there is a controllor concept, Controllor Note that two tasks need to be done:

1. Initializing the UI: Once the process is abnormal, the entire UI's business logic does not work. It is often tricky to deal with, and it is often possible to return to the previous UI or to exit the system directly.

2. Events in response to a view control: typically in an event, by invoking the service method provided at the bottom, and the background server asynchronous request, or by itself completing a front-end interaction (such as clicking a button, a dialog box pops up). If a front-end interaction is usually an event that joins another event, it is often difficult to have an appropriate treatment scheme once an event is abnormal. However, if these events are viewed as an asynchronous method, it is much simpler to link them up, only as the initiator of the call in the first user event, and subsequent operations are considered asynchronous invocations.

Therefore, the need to do a uniform exception handling is the Controllor of the process of performing page initialization, and Controllor to a user use case in the process of the first event.

We also need to analyze what system exceptions we need to encapsulate, because we need to make different policy exception handling scenarios based on their type. Common system exceptions should include the following:

Exception name	Exception description	Treatment Scenarios
Initialize exception	Exceptions that occur during initialization	The exception needs to tell the system his severity, so once an exception occurs during initialization, it may not affect the other modules, may need to go back to the previous page, and the entire system may no longer be operational. Depending on the severity of this exception, uniform exception handling can use different processing strategies.
User Cancel exception	In a complete interactive use case, the user cancels the exception that occurs when the interaction continues to complete	This exception is very common in our development time, such as using the Click New "button", jump to the new page, fill out a number of messages and then click "Cancel" button, then some of the subsequent columns of the business (such as form check, commit) should be terminated, and should return to the previous page. So for this exception, the solution is to return to the initial load state, and then do nothing.
Network exceptions	Exceptions that occur during a request to the server	For this exception to give a network request error prompt, of course, if it is a mobile device, you can also give jump to open the network settings of the interface connection, let the user reset the network configuration.
Server-side exceptions	A server-side error occurred while requesting the server, which could not be completed properly, i.e. 500 or 404 error	You may need to make different error handling scenarios based on the error code. It is important to note that server-side errors may carry the wrong prompt statements, so uniform exception handling requires the ability to prompt the user for such prompt statements
Form exception	Validation errors that occur when users fill out a form	Form validation errors are often part of the view layer, and controllor often does not handle such errors. However, there are some complex validation tasks that need to be completed with Controllor, and if the Controllor checksum fails, you need to pass the error to the view layer and then the view layer to complete the form's error prompt. So this error requires exception handling to allow the view to configure the view's own cue scheme.
...	Exceptions designed with the needs of the business or the client itself	This exception is a developer's dynamically expanding exception, and uniform exception handling allows users to register for new processing exceptions and processing policies

Basically, these exceptions can meet the needs of most clients.

3. Integration with client applications

Unified exception handling from his complexity, it is possible to use this scheme only with complex applications, so our page must be a rich client application, preferably a spa application. The spa app refers to a single-page WEB application (single-page application) that does not reload or jump the page because of user action, but instead uses JavaScript to dynamically transform the contents of the HTML to enable UI interaction with the user. This application is much more complex than a traditional web page due to the avoidance of page reload Web pages. So this application is best suited to a unified exception handling scheme.

It should also be a design pattern that takes MVC (MVVM), which separates the view logic from the system business very well. In addition, the business portion of the system and the part of the server request are separated from the controllor as far as possible, packaged into service tiers, which can be more maintainable and reusable, and the same business code is written as much as possible. If there is no unified exception handling scheme, this layered exception handling is very difficult to implement, and the use of unified exception handling, each layer only need to consider what they should do, to achieve such a front-end layering is possible.

At the same time, because of the existence of asynchronous methods, our service needs to be encapsulated using promise, and each method is best seen by name to see if he is asynchronous or synchronous. When a method is not sure whether he is asynchronous or synchronous, we should take precedence over the promise encapsulation because it is easier to transition from synchronous to asynchronous, and async code cannot be translated into synchronous code.

Finally, the specific design and code implementation, see the next section.

A unified exception handling scheme for JS Building UI (iii)