Maison  >  Article  >  Java  >  Comment gérer les retours de l'interface unifiée SpringBoot et les exceptions globales

Comment gérer les retours de l'interface unifiée SpringBoot et les exceptions globales

PHPz
PHPzavant
2023-05-12 16:01:061843parcourir

1. SpringBoot n'utilise pas de format de retour unifié

Par défaut, SpringBoot aura les trois situations de retour suivantes.

1.1 Utilisez une chaîne pour renvoyer

@GetMapping("/getUserName")
public String getUserName(){
    return "HuaGe";
}

Appelez l'interface pour renvoyer le résultat :

HuaGe

1.2 Utilisez la classe d'entité pour renvoyer

@GetMapping("/getUserName")
public User getUserName(){
    return new User("HuaGe",18,"男");
}

Appelez l'interface pour renvoyer le résultat :

{
  "name": "HuaGe",
  "age": "18",
  "性别": "男", 
}

1.3 Retour dans des circonstances anormales

@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.

2. Gameplay de base

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.

2.1 Description du paramètre

  • 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.

2.2 Description du processus

  • 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来包装返回信息,会新增很多重复代码,显得不够优雅,甚至都不好意思拿出去显摆。 肯定会有一种方式能够再一次提高代码逼格,实现最优解。

三、进阶用法

基本用法学会后,接下来看点究极版本,主要用到如下两个知识点,用法简单,无论是拿出来教学妹,还是指点小姐姐,都是必备技能。

3.1 类介绍

  • ResponseBodyAdvice: 该接口是SpringMVC 4.1提供的,它允许在 执行 @ResponseBody后自定义返回数据,用来封装统一数据格式返回;

  • @RestControllerAdvice: 该注解是对Controller进行增强的,可以全局捕获抛出的异常。

3.2 用法说明

  • 新建ResponseAdvice类;

  • 实现ResponseBodyAdvice接口,实现supportsbeforeBodyWrite方法;

  • 该类用于统一封装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字段的具体数据上是不友好或不正确的。不处理好这些事情,会严重影响自己在前端妹妹心中的高大形象的,这是决不能容忍的。

3.3 全局异常处理器

以前我们遇到异常时,第一时间想到的应该是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());
    }
}

Le résultat de l'appel est le suivant. Vous pouvez voir qu'il s'agit du type de paramètre que nous avons défini dans Result. 🎜
{
    "code": 0,
    "message": "成功",
    "data": {
        "code": 503,
        "message": "服务器正忙,请稍后再试!",
        "data": null
    }
}
🎜Bien qu'écrire de cette façon puisse répondre aux besoins quotidiens, et je pense que de nombreux amis l'utilisent de cette façon, mais si nous avons un grand nombre d'interfaces, utilisez 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);
    }
}
🎜Nous pouvons le tester via l'interface 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
    }
}

3.4 统一返回结果处理类最终版

解决上述问题非常简单,只要在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!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer