Java异常处理思路

妖狐艹你老母 2022-09-03 14:24 140阅读 0赞

### Java异常处理思路 ###

*  一、错误的异常处理示例
 *  二、异常处理思路
 *  三、checked和unchecked异常
 *  四、异常码和异常类

我自己在刚开始写代码的时候，总是有着这样的疑惑，想着请求第三方接口，或者是重要的处理步骤万一出错了，是不是得把异常处理一下。但是在看代码时发现一个现象，项目中的异常主要处理形式如下所示，代码中基本没有try-catch的异常处理语句，大部分的异常直接向上层抛出。关于异常处理自己也查了一些资料和师兄讨论过，所以专门学习总结一下项目中关于异常处理思路。

public void methodB() throws 自定义Excetpion{
        .......
        .......
    }
     
    if(xxxx){
       throw new 自定义Excetpion();
    }

其实对于线上系统来说，最怕的事情有这两个，所以在日常开发中为了避免这两个问题，才形成了项目中常用的异常处理规约：

1.  系统出现了异常不知道，下游用户投诉才知道出问题。
2.  出了问题之后无法快速定位到出错位置及原因。

# 一、错误的异常处理示例 #

首先来看一下如果使用try-catch或者if语句来进行异常处理的话一般是如下这种方式：

private void methodName() {
        JsonArray jsonArray = null;
        try {
            jsonArray = getMtlsById();
        } catch (Exception e) {
            logger.error("getMtlsById is error，message="+e.getMessage())
        }
    
    
        if(jsonArray != null){
            logger.info("update jsonArray,jsonArray="+jsonArray);
            updateMtls(jsonArray);
        }
        //dosomething 
    }

这段代码存在以下问题：

1.  吞掉了异常。catch中就算打印了堆栈信息，面对着每天海量的日志信息，也不会有人每天盯着日志去看，除非用户告诉你出问题了，你才会去找日志！所以看着好像很严谨的代码，其实作用并不大。
2.  异常处理再加上if语句中的空判断，当获取小资料出现异常的时候。本来需要更新jsonArray，由于没对为空的情况做处理，结果什么也没有做，什么错误也没有报，完美的避开了正确流程。

\*\*其实这是新手最容易犯的错误，到处捕获异常，到处加空判断，自以为写出了“健壮”的代码，实际上完全相反。\*\*导致的问题就是:

1.  代码可读性很差，如果看到一半代码是try-catch和空判断，代码看过一遍之后，找不清楚业务逻辑，那简直要崩溃。
2.  更加重要的掩盖了很多错误，就像上面的示例，日志是不会有人看的，我们的目的是**尽早让错误抛出来。**

\*\*  
\*\*

**所以代码要像下面这样干净整洁，重点一目了然，出异常了就甩锅给调用方处理吧。**

private void methodName() throw YoursException {
        JsonArray jsonArray  = getMtlsById();
        logger.info("update jsonArray,jsonArray="+jsonArray);
        updateMtls(jsonArray);
    }

# 二、异常处理思路 #

1.  方法在设计时，不需要额外关心失败的情况，专注于业务逻辑的实现。失败的场景通过异常抛出即可。
2.  方法在调用的过程中，即使我知道这个方法可能会失败，但不必立即处理这个异常，而是可以留到业务的边界集中进行处理。
3.  因为异常定义时就带了层次结构，可以根据异常的层次结构进行分类批量处理。
4.  如果是跨系统的调用，服务提供方要提供详细的异常信息，方便调用方排查问题。

比如说：

*  只有明显不需要关心的异常，如关闭资源的时候的io异常，可以捕获然后什么都不干，其他时候，不允许捕获异常，都抛出去，到controller处理，controller处理不了，就返回给调用方。
 *  **强调**，空判断大部分时候不需要，但有些空判断是要的，如：参数是用户输入的情况下。为啥说大部分场景是不需要的，因为如参数是其它系统传过来，或者其他地方获取的传过来的，**99.99%都不会为空，如果出现异常，就抛一个空指针到前台**。
 *  如果写了空判断，就必须测试为空和不为空二种场景，要么就不要写空判断。

# 三、checked和unchecked异常 #

在查资料的时候，大家的文章中频繁的提到checked和unchecked异常，刚开始不太明白，这里补充一下说明。Java的异常层次结构如下所示，简单来说**将派生于Error或者RuntimeException的异常称为unchecked异常，所有其他的异常成为checked异常。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70]

*  Checked exception: 继承自 Exception 类。代码需要处理 API 抛出的 checked exception，要么用 catch 语句，要么直接用 throws 语句抛出去。可以理解为编译时异常， **编译器强制要求开发人员必须处理这些异常** 。
 *  Unchecked exception: 也称 RuntimeException，它也是继承自 Exception。但所有 RuntimeException 的子类都有个特点，就是代码不需要处理它们的异常也能通过编译，所以它们称作 unchecked exception。 **RuntimeException（运行时异常）不需要try…catch…或throws 机制去处理的异常，开发人员可以根据具体情况来选择是否处理这些异常** 。

所以在日常开发中除了正确流程外的，所有预先可以判断的必须需要调用端处理的异常流程，都应该定义为checked异常，这样，可以显示的强制告诉接口调用方需要处理异常。举例，修改密码的方法如此定义: public boolean updatePwd(long userId) throws InvalidPwdException; 修改密码的过程中，可以预先判断，有可能原密码不正确，所以，通过定义一个checked异常：InvalidPwdException，显示要求调用方进行业务异常的处理；业务上无法预料的或者处理不了的异常，定义为unchecked业务异常。如在合成作战应用中，对处理不了的所有异常都统一包装为业务异常抛出。

# 四、异常码和异常类 #

可以根据是否是跨系统调用：

*  如果是长期对外提供服务的rpc接口（跨系统调用），可以选择Result + msg + errorcode方式更好；
 *  如果是应用内部的相互调用，就可以选择异常类，比如login应用，用户修改密码，有可能出现原始密码不正确的异常，用户注册，有可能出现email重复的异常，这时，根据我的理解，使用2个checked异常。

**维护异常码和异常之间的错误关系是一个非常繁杂的一件事，在异常种类较多情况下有一定优势，对用户友好，一般大型服务才会使用**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW9fX3poZW4_size_16_color_FFFFFF_t_70]: /images/20220829/187c7c5597e14df49ec01dd252561abe.png