(转)不错的前后端处理异常的方法

标签: 后端 异常 方法 | 发表时间:2019-01-02 23:16 | 作者:
出处:https://jackyrong.iteye.com
前言
在 Web 开发中, 我们经常会需要处理各种异常, 这是一件棘手的事情, 对于很多人来说, 可能对异常处理有以下几个问题:

什么时候需要捕获(try-catch)异常, 什么时候需要抛出(throws)异常到上层.
在 dao 层捕获还是在 service 捕获, 还是在 controller 层捕获.
抛出异常后要怎么处理. 怎么返回给页面错误信息.
异常处理反例
既然谈到异常, 我们先来说一下异常处理的反例, 也是很多人容易犯的错误, 这里我们同时讲到前端处理和后端处理 :

捕获异常后只输出到控制台
前端代码

$.ajax({
    type: "GET",
    url: "/user/add",
    dataType: "json",
    success: function(data){
        alert("添加成功");
    }
});
后端代码

try {
    // do something
} catch (Exception e) {
    e.printStackTrace();
}
这是见过最多的异常处理方式了, 如果这是一个添加商品的方法, 前台通过 ajax 发送请求到后端, 期望返回 json 信息表示添加结果. 但如果这段代码出现了异常:

那么用户看到的场景就是点击了添加按钮, 但没有任何反应(其实是返回了 500 错误页面, 但这里前端没有监听 error 事件, 只监听了 success 事件. 但即使加上了error: function(data) {alert("添加失败");}) 又如何呢? 到底因为啥失败了呢, 用户也不得而知.
后台 e.printStackTrace() 打印在控制台的日志也会在漫漫的日志中被埋没, 很可能会看不到输出的异常. 但这并不是最糟的情况, 更糟糕的事情是连 e.printStackTrace() 都没有, catch 块中是空的, 这样后端的控制台中更是什么都看不到了, 这段代码会像一个隐形的问题一样一直埋伏在系统中.
混乱的返回方式
前端代码

$.ajax({
    type: "GET",
    url: "/goods/add",
    dataType: "json",
    success: function(data) {
        if (data.flag) {
            alert("添加成功");
        } else {
            alert(data.message);
        }
    },
    error: function(data){
        alert("添加失败");
    }
});
后端代码

@RequestMapping("/goods/add")
@ResponseBody
public Map add(Goods goods) {
    Map map = new HashMap();
    try {
        // do something
        map.put(flag, true);
    } catch (Exception e) {
        e.printStackTrace();
        map.put("flag", false);
        map.put("message", e.getMessage());
    }
    reutrn map;
}
这种方式捕获异常后, 返回了错误信息, 且前台做了一定的处理, 看起来很完善? 但用 HashMap 中的 flag 和 message 这种字符串来当键很容易处理, 例如你这里叫 message, 别人起名叫 msg, 甚至有时手抖打错了, 怎么办? 前台再改成 msg 或其他的字符?, 前端后端这样一直来回改?
更有甚者在情况 A 的情况下, 返回 json, 在情况 B 的情况下, 重定向到某个页面, 这就更乱了. 对于这种不统一的结构处理起来非常麻烦.

异常处理规范
既然要进行统一异常处理, 那么肯定要有一个规范, 不能乱来. 这个规范包含前端和后端.

不要捕获任何异常
对的, 不要在业务代码中进行捕获异常, 即 dao、service、controller 层的所以异常都全部抛出到上层. 这样不会导致业务代码中的一堆 try-catch 会混乱业务代码.

统一返回结果集
不要使用 Map 来返回结果, Map 不易控制且容易犯错, 应该定义一个 Java 实体类. 来表示统一结果来返回, 如定义实体类:

public class ResultBean<T> {
    private int code;
    private String message;
    private Collection<T> data;

    private ResultBean() {

    }

    public static ResultBean error(int code, String message) {
        ResultBean resultBean = new ResultBean();
        resultBean.setCode(code);
        resultBean.setMessage(message);
        return resultBean;
    }

    public static ResultBean success() {
        ResultBean resultBean = new ResultBean();
        resultBean.setCode(0);
        resultBean.setMessage("success");
        return resultBean;
    }

    public static <V> ResultBean<V> success(Collection<V> data) {
        ResultBean resultBean = new ResultBean();
        resultBean.setCode(0);
        resultBean.setMessage("success");
        resultBean.setData(data);
        return resultBean;
    }

    // getter / setter 略
}
正常情况: 调用 ResultBean.success() 或 ResultBean.success(Collection<V> data), 不需要返回数据, 即调用前者, 需要返回数据, 调用后者. 如:
@RequestMapping("/goods/add")
@ResponseBody
public ResultBean<Goods> getAllGoods() {
    List<Goods> goods = goodsService.findAll();
    return ResultBean.success(goods);
}
@RequestMapping("/goods/update")
@ResponseBody
public ResultBean updateGoods(Goods goods) {
    goodsService.update(goods);
    return ResultBean.success();
}
一般只有查询方法需要调用 ResultBean.success(Collection<V> data) 来返回 N 条数据, 其他诸如删除, 修改等方法都应该调用 ResultBean.success(), 即在业务代码中只处理正确的功能, 不对异常做任何判断. 也不需要对 update 或 delete 的更新条数做判断(个人建议, 实际需要根据业务). 只要没有抛出异常, 我们就认为用户操作成功了. 且操作成功的提示信息在前端处理, 不要后台返回 “操作成功” 等字段.

前台接受到的信息为:

{
    "code": 0,
    "message": "success",
    "data": [
        {
            "name": "商品1",
            "price": 50.00,
        },
        {
            "name": "商品2",
            "price": 99.99,
        }
    ]
}
抛出异常: 抛出异常后, 我们应该调用 ResultBean.error(int code, String message), 来将状态码和错误信息返回, 我们约定 code 为 0 表示操作成功, 1 或 2 等正数表示用户输入错误, -1, -2 等负数表示系统错误.
前台接受到的信息为:

{
    "code": -1,
    "message": "XXX 参数有问题, 请重新填写",
    "data": null
}
前端统一处理:
返回的结果集规范后, 前端就很好处理了:

/**
* 显示错误信息
* @param result: 错误信息
*/
function showError(s) {
    alert(s);
}

/**
* 处理 ajax 请求结果
* @param result: ajax 返回的结果
* @param fn: 成功的处理函数 ( 传入data: fn(result.data) )
*/
function handlerResult(result, fn) {
    // 成功执行操作,失败提示原因
    if (result.code == 0) {
        fn(result.data);
    }
    // 用户操作异常, 这里可以对 1 或 2 等错误码进行单独处理, 也可以 result.code > 0 来粗粒度的处理, 根据业务而定.
    else if (result.code == 1) {
        showError(result.message);
    }
    // 系统异常, 这里可以对 -1 或 -2 等错误码进行单独处理, 也可以 result.code > 0 来粗粒度的处理, 根据业务而定.
    else if (result.code == -1) {
        showError(result.message);
    }
    // 如果进行细粒度的状态码判断, 那么就应该重点注意这里没出现过的状态码. 这个判断仅建议在开发阶段保留用来发现未定义的状态码.
    else {
        showError("出现未定义的状态码:" + result.code);
    }
}

/**
* 根据 id 删除商品
*/
function deleteGoods(id) {
    $.ajax({
        type: "GET",
        url: "/goods/delete",
        dataType: "json",
        success: function(result){
            handlerResult(result, deleteDone);
        }
    });
}

function deleteDone(data) {
    alert("删除成功");
}
showError 和 handlerResult 是公共方法, 分别用来显示错误和统一处理结果集.

然后将主要精力放在发送请求和处理正确结果的方法上即可, 如这里的 deleteDone 函数, 用来处理操作成功给用户的提示信息, 正所谓各司其职, 前端负责操作成功的消息提示更合理, 而错误信息只有后台知道, 所以需要后台来返回.

后端统一处理异常
说了这么多, 还没讲到后端不在业务层捕获任何异常的事, 既然所有业务层都没有捕获异常, 那么所有的异常都会抛出到 Controller 层, 我们只需要用 AOP 对 Controller 层的所有方法处理即可.

好在 Spring 为我们提供了一个注解, 用来统一处理异常:

@ControllerAdvice
@ResponseBody
public class WebExceptionHandler {

    private static final Logger log = LoggerFactory.getLogger(WebExceptionHandler.class);

    @ExceptionHandler
    public ResultBean unknownAccount(UnknownAccountException e) {
        log.error("账号不存在", e);
        return ResultBean.error(1, "账号不存在");
    }

    @ExceptionHandler
    public ResultBean incorrectCredentials(IncorrectCredentialsException e) {
        log.error("密码错误", e);
        return ResultBean.error(-2, "密码错误");
    }

    @ExceptionHandler
    public ResultBean unknownException(Exception e) {
        log.error("发生了未知异常", e);
        // 发送邮件通知技术人员.
        return ResultBean.error(-99, "系统出现错误, 请联系网站管理员!");
    }
}
在这里统一配置需要处理的异常, 同样, 对于未知的异常, 一定要及时发现, 并进行处理. 推荐出现未知异常后发送邮件, 提示技术人员.

总结
总结一下统一异常处理的方法:

不使用随意返回各种数据类型, 要统一返回值规范.
不在业务代码中捕获任何异常, 全部交由 @ControllerAdvice 来处理.
一个简单的演示项目: https://github.com/zhaojun1998/exception-handler-demo

已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [后端 异常 方法] 推荐:

(转)不错的前后端处理异常的方法

- - jackyrong
在 Web 开发中, 我们经常会需要处理各种异常, 这是一件棘手的事情, 对于很多人来说, 可能对异常处理有以下几个问题:. 什么时候需要捕获(try-catch)异常, 什么时候需要抛出(throws)异常到上层. 在 dao 层捕获还是在 service 捕获, 还是在 controller 层捕获.

后端分布式系列:分布式存储-HDFS 异常处理与恢复

- - mindwind
在前面的文章 《HDFS DataNode 设计实现解析》 中我们对文件操作进行了描述,但并未展开讲述其中涉及的异常错误处理与恢复机制. 本文将深入探讨 HDFS 文件操作涉及的错误处理与恢复过程. 读文件可能发生的异常有两种:. 读取过程中 DataNode 挂了. 因为读文件不涉及数据的改变,所以处理起来相对简单,恢复机制的透明性和易用性都非常好.

Redis持久化文件异常原因以及修复方法

- - 丕子
上线了Redis的模块,昨天Redis Server重启了,但是Redis Instance起不来了,同学联系我,我也不知道具体情况,就猜了几个原因:1、持久化文件可能太大,没load完,所以短时间内启动不了.  2、主从配置文件被sentinel修改乱了. 最后查了下原因,是由于机房突然断电导致redis aof持久化文件写入异常,这个问题详见: link.

五种常用异常值检测方法 - 安全内参 | 决策者的网络安全知识库

- -
选自towardsdatacience,作者:Will Badr. 机器之心编译 参与:韩放、shooting. 通过鉴别故障来检测异常对任何业务来说都很重要. 本文作者总结了五种用于检测异常的方法,下面一起来看看吧. 在统计学中,离群点是并不属于特定族群的数据点,是与其它值相距甚远的异常观测. 离群点是一种与其它结构良好的数据不同的观测值.

Java异常

- - CSDN博客推荐文章
“好的程序设计语言能够帮助程序员写出好程序,但是无论哪种语言都避免不了程序员写出坏的程序.                                                                                                                          ----《Java编程思想》.

浅谈java异常

- - 移动开发 - ITeye博客
在《java编程思想》中这样定义 异常:阻止当前方法或作用域继续执行的问题. 虽然java中有异常处理机制,但是要明确一点,决不应该用"正常"的态度来看待异常. 绝对一点说异常就是某种意义上的错误,就是问题,它可能会导致程序失败. 之所以java要提出异常处理机制,就是要告诉开发人员,你的程序出现了不正常的情况,请注意.

Oracle 异常处理

- - 编程语言 - ITeye博客
使用RAISE_APPLICATION_ERROR存储过程. ============================================================ */ --演示该存储过程 BEGIN. RAISE_APPLICATION_ERROR(-20000, 'Account past due.');-- explicitly raise exception END; --创建子程序 CREATE OR REPLACE PROCEDURE account_status (.

Google和SugarSync访问异常

- Freeman - 月光博客
  今天下午,Https的Google出现了短时间的访问异常,国内各地网友发现其访问出现不稳定状态,有时可以访问,有时无法访问.   这对中国用户最直接的影响是,很多用户无法访问Https版Google Reader,还有一些用户无法登录Gmail邮箱.   今天的另一个坏消息是,知名美国云存储服务SugarSync网站的域名被关键字屏蔽,目前已经无法从中国访问,虽然SugarSync的上传速度比起Dropbox还有差距,但至少美国的服务用起来放心一些,早先云存储服务Dropbox被屏蔽时不少网友转到了SugarSync这个服务,不过值得庆幸的是,该服务的电脑客户端和iPhone手机端都可以正常使用,上传和下载文件都没有问题.

spring mvc 异常处理(转)

- - 编程语言 - ITeye博客
链接:http://gaojiewyh.iteye.com/blog/1297746 (附源码). 链接:http://zywang.iteye.com/blog/983801 . 链接:http://www.cnblogs.com/xguo/p/3163519.html . 链接:http://fuliang.iteye.com/blog/947191 .

Oracle异常处理概念

- - Oracle - 数据库 - ITeye博客
5.1.1 预定义的异常处理. 5.1.2 非预定义的异常处理. 5.1.3 用户自定义的异常处理. 5.1.4  用户定义的异常处理. 5.2.1 在执行部分引发异常错误. 5.2.2 在声明部分引发异常错误. 5.3 异常错误处理编程. 5.4  在 PL/SQL 中使用 SQLCODE, SQLERRM异常处理函数.