Shulou(Shulou.com)06/01 Report--

This article mainly explains "Why to standardize exception handling in Java". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn why exception handling is standardized in Java.

1. Why do you need standard exception handling?

First of all, standardizing exception handling is also for better maintenance in the later stage, reducing program errors, and don't try {} catch () {} everywhere. For me with obsessive-compulsive disorder, normative exception handling is essential; normative exception handling can make your code cleaner and cleaner.

two。 Exception handling classification

Exception handling:

Service throws an exception, controller unifies try {} catch () {}

Try {} catch () {} handle some io or http request exceptions that can be handled directly.

Controller does not handle exceptions, but uses @ ControllerAdvice to define some types of exceptions.

ControllerAdvicepublic class WebExceptionHandler {@ ExceptionHandler ({BizException.class}) @ ResponseStatus (HttpStatus.OK) public String processBizException (HttpServletRequest request, BizException e) {LOG.error ("BizException", e); request.setAttribute ("msg", e.getMsg ()); return "common/error";}}

Exception classification:

Request mode exception

Parameter exception, such as: @ RequestParam is used but the parameter is not passed when the request is made. The framework will throw an exception to handle @ ControllerAdvice globally.

Business exception, such as: user does not exist, CAPTCHA is invalid, business exception can be classified according to different business, user exception, account exception.

System exception, such as: incorrect parameters result in multiple result sets queried

Classify the exception code of the requestor:

Public enum ReturnCodeEnum {SUCCESS ("0000", "request successful"), MERCHANT_ERROR ("0001", "Merchant exception"), ORDER_IS_NULL ("0002", "original order does not exist"), WAITING_PAYER_CONFIRM ("9995", "waiting for customer confirmation"), WAITING ("9996", "request processing"), FAIL ("9997", "request failed"), BIZ_ERROR ("9998") "Business exception"), SYSTEM_EXCEPTION ("9999", "system exception") }

Internal exception coding classification:

/ * * Bank sets exception class * / public class BankBizException extends BizException {private static final long serialVersionUID = 3536909333010163563L; / * * No channel shunting setting * * / public static final int CHANNEL_FLOW_IS_NULL = 101; / * request parameter exception * / public static final int REQUEST_PARAM_ERRO = 102 / * * Bank channel configuration error * * / public static final int BANK_CHANNEL_ERRO = 103; / * * Bank channel error * * / public static final int BANK_WAY_ERROR = 104; / * * subsidiary information of bank channel for sub-merchants is empty * * / public static final int BANK_SUBMERCHANT_INFO_IS_NULL = 105 / * * the subsidiary information of the bank channel of the sub-merchant is misconfigured * * / public static final int BANK_SUBMERCHANT_INFO_IS_ERROR = 106; / * * verify that the parameters passed by the bank channel do not meet the requirements * / public static final int BANK_CHANNEL_RULE_VALIDA_PARAM_ERROR = 107 / * * wrong opening time of agui bank channel * * / public static final int BANK_CHANNEL_DATE_ERRO = 108;}

Why is it that exception coding is managed uniformly by distinguishing between requesters and internally?

First of all, we need to give the requestor a unified request and response coding table, which allows the requester to classify according to different exception codes, while the internal exception coding is for the internal statistics or recording of abnormal information within the platform, which is more conducive to troubleshooting. To be clear about the message of a business exception, you can return the location error directly to the requester, but the system exception message cannot be returned directly to the requester. You can prompt: system exception, please try again later, because the exception message may be thrown by the framework and needs to be handled manually. We can only record these exception LOG logs regularly and optimize the classification later.

At this point, I believe you have a deeper understanding of "Why to standardize exception handling in Java". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.