task that does not conform to the preset rules can be called abnormality. Any business logic operation will delineate some boundaries or rules, but often things backfire, there will always be naughty ghosts to challenge the robustness of the system. These naughty ghosts include:
1. System users. Not all users know the unspoken rules. For example, the user only has 100 yuan in the bank account, but the user directly withdraws 200 yuan without inquiring.
2. Developers. Coders are sometimes overconfident. For example, if you ignore the file download function when writing the file download function, this branching process may not exist.
3. Operating environment. The software system also depends on the sky, and no one can guarantee that the network will always be smooth and the hard disk will always be stable.
[Exception Handling Framework]
If there is a problem, we must solve the problem. If the problem cannot be solved, then minimize the impact of the problem. The same is true for exceptions. In order to improve robustness, compatibility with exceptions is required. A very important principle in handling exceptions is not to escape, not to distort. Swallowing exceptions is as sinful as providing wrong exception information. The exception handling framework can be roughly divided into the following points:
1. Exception class encapsulation. According to the cause of the exception, we encapsulate the exception into two categories, namely business logic exception (BusinessException) and system programming exception (ProgramException). The purpose of classification is to classify and process.
2. Anomaly detection class. This is where exceptions are generated, including business logic detection (encapsulating exception throwing for situations that do not conform to business logic), as well as converting and encapsulating underlying exceptions (such as capturing and encapsulating exceptions generated by database operations as ProgramException).
3. Exception handling class. This is the end point of the exception, where the exception will be elegantly displayed to the system operators and users of the system in a more appropriate way (such as recording logs or page prompts).
At the same time, for a unified coding style, we make the following conventions for exception handling:
1. Only the level closest to the user will finally handle the exception. This user includes real natural person users of the system, as well as some systems, such as timers or command line interaction. The other layers are only responsible for catching the underlying exception and passing it up.
2. For system programming abnormalities, a unified prompt is given to users, and abnormal logs are recorded, and monitoring and alarming are carried out by monitoring system users and system operation and maintenance personnel.
3. For business logic exceptions, user-friendly prompts need to be provided according to different exception types and contexts. At the same time, considering that the prompts for users are part of the product copy and may change frequently, it is necessary to configure the prompts in the form of "error code-prompt".
4. In order to facilitate the unified management of error codes, agree on the coding rules of error codes: [error message type (one-digit)] + [system group number (two-digit)] + [subsystem number (two-digit)] + [Sequence number (two digits)].
5. The value of the error message type: E - ordinary error message; W - warning message; Q - inquiry message; F - fatal error message
[WEB engineering exception handling]
For the WEB system, because we use the It's the Spring MVC framework because it's described for that kind of framework.
1. Encapsulate two entity classes: BisinessException and SystemException.
2. Add the implementation class MyExceptionHandler of the HandlerExceptionResolver interface. The code is as follows:
public class MyExceptionHandler implements HandlerExceptionResolver {
public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler,
Exception ex) {
Map<String, Object> model = new HashMap<String, Object>();
model.put("ex", ex);
// redirect to different pages according to different errors
if(ex instanceof BusinessException) {
return new ModelAndView("error-business", model);
}else if(ex instanceof ParameterException) {
return new ModelAndView("error-parameter", model);
} else {
return new ModelAndView("error", model);
}
}
}
3. Add the following content to the Spring configuration file applicationContext.xml:
<bean id="exceptionHandler" class="cn.basttg.core.exception.MyExceptionHandler"/>
4. For Unchecked Exception, add the corresponding errorpage:
<error-page> <exception-type>java.lang.Throwable</exception-type> <location>/500.jsp</location> </error-page> <error-page> <error-code>500</error-code> <location>/500.jsp</location> </error-page> <error-page> <error-code>404</error-code> <location>/404.jsp</location> </error-page>
5. The system adopts the same error page as the system style.
[References]
1. http://cgs1999.iteye.com/blog/1547197