异常处理分析

最新推荐文章于 2022-06-07 19:26:07 发布

da297368860

最新推荐文章于 2022-06-07 19:26:07 发布

阅读量472

点赞数

分类专栏： JAVA 文章标签： java spring

本文链接：https://blog.csdn.net/da297368860/article/details/120561803

版权

JAVA 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

一、简介

异常，也称为例外，是在程序运行过程中发生的、会打断程序正常执行的事件。把它置于代码层面来理解，即阻止了当前方法或作用域继续执行。在Java中，异常被当做对象来处理，其基类是Throwable。
Throwable(所有error和exception的父类)

1、error

Error表示编译时和系统错误，表示系统在运行期间出现了严重的错误，属于不可恢复的错误，一般是环境的问题或者JVM的问题，并非程序的问题；因此这种错误会导致程序终止执行，应用程序是无法处理此类错误的。Error不在我们调试代码可以处理的范围中。

2、exception

Exception表示可以恢复的异常，是编译器可以捕捉到的，由java应用程序抛出的非严重型错误，又分为检查异常和运行时异常。

二、异常处理

捕获
	try： 执行可能产生异常的代码
  Catch： 异常捕获
	Finally： 无论是否发生异常总能执行的代码

抛出
	Throw： 手动抛出异常
 	Throws： 声明方法可能要抛出的各种异常

1、常见的处理模式

1、流水线”的方式进行异常处理，也就是统一为所有方法打上 try…catch…捕获所有异常记录日志
2、使用 AOP 来进行类似的“统一异常处理”

2、捕获和处理异常容易犯的错

“统一异常处理”方式正是常见的第一个错：不在业务代码层面考虑异常处理，仅在框架层面粗犷捕获和处理异常。

	Repository 层出现异常或许可以忽略，或许可以降级，或许需要转化为一个友好的异常。如果一律捕获异常仅记录日志，很可能业务逻辑已经出错，而用户和程序本身完全感知不到。

	Service 层往往涉及数据库事务，出现异常同样不适合捕获，否则事务无法自动回滚。此外 Service 层涉及业务逻辑，有些业务逻辑执行中遇到业务异常，可能需要在异常后转入分支业务流程。如果业务异常都被框架捕获了，业务功能就会不正常。

	如果下层异常上升到 Controller 层还是无法处理的话，Controller 层往往会给予用户友好提示，或是根据每一个 API 的异常表返回指定的异常类型，同样无法对所有异常一视同仁。

因此，我不建议在框架层面进行异常的自动、统一处理，尤其不要随意捕获异常。但，框架可以做兜底工作。如果异常上升到最上层逻辑还是无法处理的话，可以以统一的方式进行异常转换，比如通过 @RestControllerAdvice + @ExceptionHandler，来捕获这些“未处理”异常。
■ 对于自定义的业务异常，以 Warn 级别的日志记录异常以及当前 URL、执行方法等信息后，提取异常中的错误码和消息等信息，转换为合适的 API 包装体返回给 API 调用方；
■ 对于无法处理的系统异常，以 Error 级别的日志记录异常和上下文信息（比如 URL、参数、用户 ID）后，转换为普适的“服务器忙，请稍后再试”异常信息，同样以 API 包装体返回给调用方。
比如，下面这段代码的做法：


@RestControllerAdvice
@Slf4j
public class RestControllerExceptionHandler {
    private static int GENERIC_SERVER_ERROR_CODE = 2000;
    private static String GENERIC_SERVER_ERROR_MESSAGE = "服务器忙，请稍后再试";

    @ExceptionHandler
    public APIResponse handle(HttpServletRequest req, HandlerMethod method, Exception ex) {
        if (ex instanceof BusinessException) {
            BusinessException exception = (BusinessException) ex;
            log.warn(String.format("访问 %s -> %s 出现业务异常！", req.getRequestURI(), method.toString()), ex);
            return new APIResponse(false, null, exception.getCode(), exception.getMessage());
        } else {
            log.error(String.format("访问 %s -> %s 出现系统异常！", req.getRequestURI(), method.toString()), ex);
            return new APIResponse(false, null, GENERIC_SERVER_ERROR_CODE, GENERIC_SERVER_ERROR_MESSAGE);
        }
    }
}

出现运行时系统异常后，异常处理程序会直接把异常转换为 JSON 返回给调用方。
在这里插入图片描述第二个错，捕获了异常后直接生吞。在任何时候，我们捕获了异常都不应该生吞，也就是直接丢弃异常不记录、不抛出。这样的处理方式还不如不捕获异常，因为被生吞掉的异常一旦导致 Bug，就很难在程序中找到蛛丝马迹，使得 Bug 排查工作难上加难。
通常情况下，生吞异常的原因，可能是不希望自己的方法抛出受检异常，只是为了把异常“处理掉”而捕获并生吞异常，也可能是想当然地认为异常并不重要或不可能产生。但不管是什么原因，不管是你认为多么不重要的异常，都不应该生吞，哪怕是一个日志也好。

第三个错，丢弃异常的原始信息。我们来看两个不太合适的异常处理方式，虽然没有完全生吞异常，但也丢失了宝贵的异常信息。
比如有这么一个会抛出受检异常的方法 readFile：


private void readFile() throws IOException {
  Files.readAllLines(Paths.get("a_file"));
}

像这样调用 readFile 方法，捕获异常后，完全不记录原始异常，直接抛出一个转换后异常，导致出了问题不知道 IOException 具体是哪里引起的：

@GetMapping("wrong1")
    public void wrong1() {
        try {
            readFile();
        } catch (IOException e) {
            // 捕获异常后，完全不记录原始异常，直接抛出一个转换后异常，导致出了问题不知道 IOException 具体是哪里引起的
            throw new RuntimeException("系统忙请稍后再试");
        }
    }

或者是这样，只记录了异常消息，却丢失了异常的类型、栈等重要信息：

@GetMapping("wrong2")
public void wrong2() {
    try {
        readFile();
    } catch (IOException e) {
        log.error("文件读取错误, {}", e.getMessage());
        throw new RuntimeException("系统忙请稍后再试");
    }
}

留下的日志是这样的，看完一脸茫然，只知道文件读取错误的文件名，至于为什么读取错误、是不存在还是没权限，完全不知道。
在这里插入图片描述第四个错，抛出异常时不指定任何消息。我见过一些代码中的偷懒做法，直接抛出没有 message 的异常。

@GetMapping("wrong3")
public void wrong3() {
    try {
        readFile();
    } catch (Exception e) {
        // log.error("文件读取错误", e);
        // java.lang.RuntimeException: null
        throw new RuntimeException();
    }
}

这么写的同学可能觉得永远不会走到这个逻辑，永远不会出现这样的异常。但，这样的异常却出现了，被 ExceptionHandler 拦截到后输出了下面的日志信息：
在这里插入图片描述总之，如果你捕获了异常打算处理的话，除了通过日志正确记录异常原始信息外，通常还有三种处理模式：
■ 转换，即转换新的异常抛出。对于新抛出的异常，最好具有特定的分类和明确的异常消息，而不是随便抛一个无关或没有任何信息的异常，并最好通过 cause 关联老异常。
■ 重试，即重试之前的操作。比如远程调用服务端过载超时的情况，盲目重试会让问题更严重，需要考虑当前情况是否适合重试。
■ 恢复，即尝试进行降级处理，或使用默认值来替代原始数据。以上，就是通过 catch 捕获处理异常的一些最佳实践。

3、小心 finally 中的异常

有些时候，我们希望不管是否遇到异常，逻辑完成后都要释放资源，这时可以使用 finally 代码块而跳过使用 catch 代码块。
但要千万小心 finally 代码块中的异常，因为资源释放处理等收尾操作同样也可能出现异常。比如下面这段代码，我们在 finally 中抛出一个异常：

@GetMapping("wrong")
public void wrong() {
    try {
        log.info("try");
        //异常丢失
        throw new RuntimeException("try");
    } finally {
        log.info("finally");
        throw new RuntimeException("finally");
    }
}

最后在日志中只能看到 finally 中的异常，虽然 try 中的逻辑出现了异常，但却被 finally 中的异常覆盖了。这是非常危险的，特别是 finally 中出现的异常是偶发的，就会在部分时候覆盖 try 中的异常，让问题更不明显：
在这里插入图片描述至于异常为什么被覆盖，原因也很简单，因为一个方法无法出现两个异常。修复方式是，finally 代码块自己负责异常捕获和处理：

@GetMapping("right")
public void right() {
    try {
        log.info("info try");
        throw new RuntimeException("error try");
    } finally {
        log.info("info finally");
        try {
            throw new RuntimeException("error1 finally");
        } catch (Exception ex) {
            log.error("error2 finally", ex);
        }
    }
}

在这里插入图片描述或者可以把 try 中的异常作为主异常抛出，使用 addSuppressed 方法把 finally 中的异常附加到主异常上：

@GetMapping("right2")
public void right2() throws Exception {
    Exception e = null;
    try {
        log.info("info try");
        throw new RuntimeException("error try");
    } catch (Exception ex) {
        e = ex;
    } finally {
        log.info("into finally");
        try {
            throw new RuntimeException("error1 finally");
        } catch (Exception ex) {
            if (e != null) {
                e.addSuppressed(ex);
            } else {
                e = ex;
            }
        }
    }
    throw e;
}

在这里插入图片描述其实这正是 try-with-resources 语句的做法，对于实现了 AutoCloseable 接口的资源，建议使用 try-with-resources 来释放资源，否则也可能会产生刚才提到的，释放资源时出现的异常覆盖主异常的问题。比如如下我们定义一个测试资源，其 read 和 close 方法都会抛出异常：

public class TestResource implements AutoCloseable {
    public void read() throws Exception{
        throw new Exception("read error");
    }
    @Override
    public void close() throws Exception {
        throw new Exception("close error");
    }
}

使用传统的 try-finally 语句，在 try 中调用 read 方法，在 finally 中调用 close 方法：

@GetMapping("useresourcewrong")
public void useresourcewrong() throws Exception {
    TestResource testResource = new TestResource();
    try {
        testResource.read();
    } finally {
        // 同样出现了 finally 中的异常覆盖了 try 中异常的问题
        testResource.close();
    }
}

在这里插入图片描述而改为 try-with-resources 模式之后：

@GetMapping("useresourceright")
public void useresourceright() throws Exception {
    // try-with-resources 模式
    try (TestResource testResource = new TestResource()) {
        testResource.read();
    }
}

在这里插入图片描述

4、千万别把异常定义为静态变量

既然我们通常会自定义一个业务异常类型，来包含更多的异常信息，比如异常错误码、友好的错误提示等，那就需要在业务逻辑各处，手动抛出各种业务异常来返回指定的错误码描述（比如对于下单操作，用户不存在返回 2001，商品缺货返回 2002 等）。
对于这些异常的错误代码和消息，我们期望能够统一管理，而不是散落在程序各处定义。这个想法很好，但稍有不慎就可能会出现把异常定义为静态变量的坑。

三、总结

1、注意捕获和处理异常

首先，不应该用 AOP 对所有方法进行统一异常处理，异常要么不捕获不处理，要么根据不同的业务逻辑、不同的异常类型进行精细化、针对性处理；其次，处理异常应该杜绝生吞，并确保异常栈信息得到保留；最后，如果需要重新抛出异常的话，请使用具有意义的异常类型和异常消息。

2、务必小心 finally 代码块中资源回收逻辑

确保 finally 代码块不出现异常，内部把异常处理完毕，避免 finally 中的异常覆盖 try 中的异常；或者考虑使用 addSuppressed 方法把 finally 中的异常附加到 try 中的异常上，确保主异常信息不丢失。此外，使用实现了 AutoCloseable 接口的资源，务必使用 try-with-resources 模式来使用资源，确保资源可以正确释放，也同时确保异常可以正确处理。

3、小心静态变量的异常定义

虽然在统一的地方定义收口所有的业务异常是一个不错的实践，但务必确保异常是每次 new 出来的，而不能使用一个预先定义的 static 字段存放异常，否则可能会引起栈信息的错乱。

4、确保正确处理了线程池中任务的异常

如果任务通过 execute 提交，那么出现异常会导致线程退出，大量的异常会导致线程重复创建引起性能问题，我们应该尽可能确保任务不出异常，同时设置默认的未捕获异常处理程序来兜底；如果任务通过 submit 提交意味着我们关心任务的执行结果，应该通过拿到的 Future 调用其 get 方法来获得任务运行结果和可能出现的异常，否则异常可能就被生吞了。

四、源码

https://gitee.com/smartschool/exception-handling

da297368860

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
打赏
0
评论
异常处理分析

一、简介异常，也称为例外，是在程序运行过程中发生的、会打断程序正常执行的事件。把它置于代码层面来理解，即阻止了当前方法或作用域继续执行。在Java中，异常被当做对象来处理，其基类是Throwable。Throwable(所有error和exception的父类)1、errorError表示编译时和系统错误，表示系统在运行期间出现了严重的错误，属于不可恢复的错误，一般是环境的问题或者JVM的问题，并非程序的问题；因此这种错误会导致程序终止执行，应用程序是无法处理此类错误的。Error不在我们调试代码可
复制链接

扫一扫