Architect Express 6.14-Development framework-Exception handling

Why do exceptions need to be explained in a separate section? Because exceptions are a special part of software design that requires architects to deal with their own ideas. The general framework does not provide a unified approach, and will be a lot of students forget to deal with, or it is relatively rough processing off. Think of a lot of site errors, users will see a large number of English anomalies, and even execute the SQL are included in the inside, you will not feel very unprofessional?

The first exception should be classified, and it is important to determine the classification of the exception, which is the basis for different processing at a later stage:

1. A business exception is a business error or illegal information that occurs when a user executes a business request, the occurrence of which is reasonable, should let the user see the information of the exception prompt, and does not need to record the Exception log.
2. Permissions exceptions are exceptions that occur when a user performs some business that requires special permissions, or when a user operation that is not logged in requires a login-related business, which is reasonable and does not require logging of the Exception Log. But the way of processing is different.
3. System anomaly, there are some unpredictable situations such as db down, this kind of exception should not appear, the need to record the log, and such exceptions need to be alerted in a timely manner, and the user should not see the specific error message, this time should prompt more elegant error information, such as: The site may be in maintenance, please try again later, If the retry fails, please click Submit exception to the relevant person, we will deal with it in time.

These 3 types of exceptions are the base classes for all exceptions, and of course the larger the system, the 3 classes of exceptions need to be subdivided for more granular processing. Of course, we will not start again, first of all, how to deal with these 3 kinds of exceptions to discuss.

Again, the way the user requests:

1. Page Jump
2. Ajax requests +ajax cross-domain requests

There are 4 things you can do for each request type:

1. Request normal, Normal return
2. Request a business exception to show to the user
3. Request permission exception, require user to log in or request permission
4. Request a system exception, system alarm, to user prompt, try to recover

So how do you deal with the exception of the uniform?

1. First, to confirm the normal request and AJAX requests and Ajax cross-domain requests, it is recommended to use the suffix to distinguish JSON is the AJAX request, if it is a JSON way and contains the callback parameter is a cross-domain request.
2. To make a unified exception interceptor, first distinguish between these 3 ways, and then use different handler to process.
3. In each handler, different processing logic is made for different exceptions in 3.
   1. Page Jump + Business exception, unified processing method is to jump to the unified business prompt interface, prompting the user corresponding error message, and then on the page can choose to return to the previous page. Of course, you can also let the user in the Controller's method to mark the custom error handling mode @fail ("I want to jump to the page"), the error message will be placed in the context, the page jumps to the display.
   2. Page Jump + permission exception, transfer to login page or permission request page
   3. Page Jump + system exception, jump to the unified error page, triggering the alarm, but do not display the error details on the page, the user can choose to return to retry, or submit error reports.
   4. ajax+ Business exception, this is the simplest, directly prompt the error message is OK.
   5. ajax+ permission exception, according to different categories for page jump.
   6. ajax+ system exception, triggering the alarm, but do not display the error details on the page, the user can choose to retry, or submit an error report
   7. Cross-domain just need to increase callback, other with Ajax.
4. Where Ajax, need to do a uniform encapsulation, for the different errors of the request processing, in addition to send AJAX requests, if the page refresh terminates, pay attention to catch Ajax exceptions, do not prompt out.
5. Of course, for permission exceptions, we will also open a special section to explain.

After such a package, the developer only needs to throw an exception when needed. A novice programmer can easily throw their own exceptions without worrying about what is going on behind the exception.

In addition, if the complexity of the system increases, you can increase the subclass of the exception and perform different exception handling. In addition, the system can also perform automatic compensation mechanism, such as db down, try to restart the service, hehe, of course, the latter can be structured to avoid such problems in the way possible.

Architect Express 6.14-Development framework-Exception handling