Par défaut, SpringBoot aura les trois situations de retour suivantes.
@GetMapping("/getUserName") public String getUserName(){ return "HuaGe"; }
Appelez l'interface pour renvoyer le résultat :
HuaGe
@GetMapping("/getUserName") public User getUserName(){ return new User("HuaGe",18,"男"); }
Appelez l'interface pour renvoyer le résultat :
{ "name": "HuaGe", "age": "18", "性别": "男", }
@GetMapping("/getUserName") public static String getUserName(){ HashMap hashMap = Maps.newHashMap(); return hashMap.get(0).toString(); }
Simulez une exception de pointeur nul, sinon lors de la gestion d'une exception, vous pouvez consulter le résultat de retour par défaut de SpringBoot :
{ "timestamp": "2021-08-09T06:56:41.524+00:00", "status": 500, "error": "Internal Server Error", "path": "/sysUser/getUserName" }
Pour les situations ci-dessus, si l'ensemble du projet ne définit pas un format de retour unifié, cinq backend les développeurs définissent cinq formats de retour de cette façon, non seulement le code est gonflé, l'efficacité de l'amarrage front-end et back-end est faible, mais également des situations inattendues peuvent survenir, comme l'affichage direct de détails anormaux par le front-end, etc. ., ce qui donne à l’utilisateur une très mauvaise expérience.
La chose la plus courante dans les projets est d'encapsuler une classe d'outils. Les informations de champ qui doivent être renvoyées sont définies dans la classe et les informations d'interface qui doivent être renvoyées au front-end sont encapsulées. à travers cette classe, afin que l'incohérence dans le format de retour puisse être résolue.
code : code d'état, un ensemble unifié de codes d'état peut être conservé en arrière-plan
message : informations de description, informations d'invite pour le succès/l'échec de l'appel d'interface ; ;
data : Renvoie les données.
Créer une nouvelle classe de résultats
public class Result<T> { private int code; private String message; private T data; public Result() {} public Result(int code, String message) { this.code = code; this.message = message; } /** * 成功 */ public static <T> Result<T> success(T data) { Result<T> result = new Result<T>(); result.setCode(ResultMsgEnum.SUCCESS.getCode()); result.setMessage(ResultMsgEnum.SUCCESS.getMessage()); result.setData(data); return result; } /** * 失败 */ public static <T> Result<T> error(int code, String message) { return new Result(code, message); } }
Définir le code d'état de retour
public enum ResultMsgEnum { SUCCESS(0, "成功"), FAIL(-1, "失败"), AUTH_ERROR(502, "授权失败!"), SERVER_BUSY(503, "服务器正忙,请稍后再试!"), DATABASE_OPERATION_FAILED(504, "数据库操作失败"); private int code; private String message; ResultMsgEnum(int code, String message) { this.code = code; this.message = message; } public int getCode() { return this.code; } public String getMessage() { return this.message; } }
Utilisation
Les deux étapes ci-dessus définissent Format de retour des données
et Code d'état
, nous devons ensuite voir comment les utiliser dans l'interface. 数据返回格式
和状态码
,接下来就要看下在接口中如何使用了。
@GetMapping("/getUserName") public Result getUserName(){ return Result.success("huage"); }
调用结果如下,可以看到是我们在Result中定义的参数类型。
{ "code": 0, "message": "成功", "data": "huage" }
这样写虽然能够满足日常需求,而且我相信很多小伙伴也是这么用的,但是如果我们有大量的接口,然后在每一个接口中都使用Result.success
来包装返回信息,会新增很多重复代码,显得不够优雅,甚至都不好意思拿出去显摆。 肯定会有一种方式能够再一次提高代码逼格,实现最优解。
基本用法学会后,接下来看点究极版本,主要用到如下两个知识点,用法简单,无论是拿出来教学妹,还是指点小姐姐,都是必备技能。
ResponseBodyAdvice: 该接口是SpringMVC 4.1提供的,它允许在 执行 @ResponseBody
后自定义返回数据,用来封装统一数据格式返回;
@RestControllerAdvice: 该注解是对Controller进行增强的,可以全局捕获抛出的异常。
新建ResponseAdvice
类;
实现ResponseBodyAdvice
接口,实现supports
、beforeBodyWrite
方法;
该类用于统一封装controller中接口的返回结果。
@RestControllerAdvice public class ResponseAdvice implements ResponseBodyAdvice<Object> { @Autowired private ObjectMapper objectMapper; /** * 是否开启功能 true:是 */ @Override public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) { return true; } /** * 处理返回结果 */ @Override public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) { //处理字符串类型数据 if(o instanceof String){ try { return objectMapper.writeValueAsString(Result.success(o)); } catch (JsonProcessingException e) { e.printStackTrace(); } } return Result.success(o); } }
我们可以通过getUserName
接口测试一下,会发现和直接使用Result
返回的结果是一致的。
不过,细心的小伙伴们肯定注意到了,在ResponseAdvice
我们全部使用了Result.success(o)
来处理结果,对于error类型的结果未做处理。我们来看下,发生异常情况时,返回结果是什么样呢?继续使用上面HashMap空指针异常的代码,测试结果如下:
{ "code": 0, "message": "成功", "data": { "timestamp": "2021-08-09T09:33:26.805+00:00", "status": 405, "error": "Method Not Allowed", "path": "/sysUser/getUserName" } }
虽然格式上没有毛病,但是在code、data字段的具体数据上是不友好或不正确的。不处理好这些事情,会严重影响自己在前端妹妹心中的高大形象的,这是决不能容忍的。
以前我们遇到异常时,第一时间想到的应该是try..catch..finnal吧,不过这种方式会导致大量代码重复,维护困难,逻辑臃肿等问题,这不是我们想要的结果。
今天我们要用的全局异常处理方式,用起来是比较简单的。首先新增一个类,增加@RestControllerAdvice
注解,该注解的作用花哥上面已经介绍过,就不再唠叨了。
@RestControllerAdvice public class CustomerExceptionHandler { }
如果我们有想要拦截的异常类型,就新增一个方法,使用@ExceptionHandler
注解修饰,注解参数为目标异常类型。
例如:controller中接口发生Exception异常时,就会进入到Execption
方法中进行捕获,将杂乱的异常信息,转换成指定格式后交给ResponseAdvice
@RestControllerAdvice @Slf4j public class CustomerExceptionHandler { @ExceptionHandler(AuthException.class) public String ErrorHandler(AuthorizationException e) { log.error("没有通过权限验证!", e); return "没有通过权限验证!"; } @ExceptionHandler(Exception.class) public Result Execption(Exception e) { log.error("未知异常!", e); return Result.error(ResultMsgEnum.SERVER_BUSY.getCode(),ResultMsgEnum.SERVER_BUSY.getMessage()); } }
{ "code": 0, "message": "成功", "data": { "code": 503, "message": "服务器正忙,请稍后再试!", "data": null } }
Result.success
pour empaqueter chaque interface. Renvoyer des informations ajoutera beaucoup de code répété, ce qui n'est pas assez élégant et même embarrassant à montrer. Il doit y avoir un moyen d'améliorer à nouveau le code et d'obtenir la solution optimale. 🎜🎜3. Utilisation avancée🎜🎜Après avoir appris l'utilisation de base, jetons un coup d'œil à la version ultime. Elle utilise principalement les deux points de connaissances suivants. Elle est simple à utiliser et est indispensable si elle est utilisée pour enseigner aux filles. ou donner des conseils aux filles. 🎜🎜3.1 Introduction à la classe🎜🎜🎜🎜🎜ResponseBodyAdvice : 🎜 Cette interface est fournie par SpringMVC 4.1. Elle permet de renvoyer des données personnalisées après l'exécution de @ResponseBody
et est utilisée pour encapsuler les retours au format de données unifié 🎜🎜 ; 🎜🎜🎜@RestControllerAdvice : 🎜 Cette annotation améliore le contrôleur et peut capturer les exceptions levées à l'échelle mondiale. 🎜🎜🎜🎜3.2 Instructions d'utilisation🎜🎜🎜🎜Créer une nouvelle classe ResponseAdvice
; 🎜🎜🎜🎜implémenter l'interface ResponseBodyAdvice
et implémenter les supports
, Méthode beforeBodyWrite
; 🎜🎜🎜🎜Cette classe est utilisée pour encapsuler uniformément les résultats de retour de l'interface dans le contrôleur. 🎜🎜🎜@RestControllerAdvice public class ResponseAdvice implements ResponseBodyAdvice<Object> { @Autowired private ObjectMapper objectMapper; /** * 是否开启功能 true:开启 */ @Override public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) { return true; } /** * 处理返回结果 */ @Override public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) { //处理字符串类型数据 if(o instanceof String){ try { return objectMapper.writeValueAsString(Result.success(o)); } catch (JsonProcessingException e) { e.printStackTrace(); } } //返回类型是否已经封装 if(o instanceof Result){ return o; } return Result.success(o); } }
getUserName
, et nous constaterons que les résultats renvoyés en utilisant directement Result
sont cohérents. 🎜🎜Cependant, des amis prudents ont dû remarquer que dans ResponseAdvice
nous utilisons tous Result.success(o)
pour traiter les résultats, et qu'aucun résultat de type erreur n'est traité. . Jetons un coup d'oeil, quel est le résultat renvoyé lorsqu'une exception se produit ? En continuant à utiliser le code d'exception du pointeur nul HashMap ci-dessus, les résultats du test sont les suivants : 🎜rrreee🎜Bien qu'il n'y ait aucun problème de format, les données spécifiques dans les champs de code et de données ne sont pas conviviales ou incorrectes. Ne pas bien gérer ces questions affectera sérieusement l'image de sa grande taille dans l'esprit de la sœur frontale, ce qui ne sera jamais toléré. 🎜🎜3.3 Gestionnaire d'exceptions global🎜🎜Lorsque nous avons rencontré une exception dans le passé, la première chose qui nous est venue à l'esprit était try..catch..finnal. Cependant, cette méthode entraînera beaucoup de duplication de code, des difficultés de maintenance et une surcharge. logique et d’autres problèmes. Ce n’est pas le résultat que nous souhaitons. 🎜🎜La méthode globale de gestion des exceptions que nous allons utiliser aujourd'hui est relativement simple à utiliser. Tout d'abord, ajoutez une nouvelle classe et ajoutez l'annotation @RestControllerAdvice
. La fonction de cette annotation a été introduite ci-dessus, je n'entrerai donc pas dans les détails. 🎜rrreee🎜Si nous avons un type d'exception que nous voulons intercepter, ajoutez une nouvelle méthode et utilisez l'annotation @ExceptionHandler
pour la modifier, et le paramètre d'annotation est le type d'exception cible. 🎜🎜Par exemple : lorsqu'une exception se produit dans l'interface du contrôleur, celui-ci entrera dans la méthode Execption
pour la capturer, convertira les informations d'exception désordonnées au format spécifié et les remettra à ResponseAdvice
La méthode est encapsulée dans un format unifié et renvoyée au partenaire front-end. 🎜@RestControllerAdvice @Slf4j public class CustomerExceptionHandler { @ExceptionHandler(AuthException.class) public String ErrorHandler(AuthorizationException e) { log.error("没有通过权限验证!", e); return "没有通过权限验证!"; } @ExceptionHandler(Exception.class) public Result Execption(Exception e) { log.error("未知异常!", e); return Result.error(ResultMsgEnum.SERVER_BUSY.getCode(),ResultMsgEnum.SERVER_BUSY.getMessage()); } }
再次调用接口getUserName
查看返回结果,会发现还是有一些问题,因为我们在CustomerExceptionHandler
中已经将接口返回结果封装成Result
类型,而代码执行到统一结果返回类ResponseAdvice
时,又会结果再次封装,就出现了如下问题。
{ "code": 0, "message": "成功", "data": { "code": 503, "message": "服务器正忙,请稍后再试!", "data": null } }
解决上述问题非常简单,只要在beforeBodyWrite
中增加一条判断即可。
@RestControllerAdvice public class ResponseAdvice implements ResponseBodyAdvice<Object> { @Autowired private ObjectMapper objectMapper; /** * 是否开启功能 true:开启 */ @Override public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) { return true; } /** * 处理返回结果 */ @Override public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) { //处理字符串类型数据 if(o instanceof String){ try { return objectMapper.writeValueAsString(Result.success(o)); } catch (JsonProcessingException e) { e.printStackTrace(); } } //返回类型是否已经封装 if(o instanceof Result){ return o; } return Result.success(o); } }
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!