Java异常处理总结，天瑞地安技术大咖分享干货

15127507001

    不要问小编为什么要写这样一篇内容，也没什么，主要是天瑞地安的程序猿们“抽疯”，非得抓着小编帮他们转述关于他们十年工作总结——JAVA异常处理！既然程序猿们都“抽疯”要公布各自技巧了，小编也没什么好怕的！

    Java异常处理机制的目的，在于通过使用少于目前数量的代码来简化大型项目代码，提高项目的可靠性安全性，属于那种投入少但效果立竿见影的语言特性。先来回顾回顾下基本知识点。

一、几个异常基本语法

1.异常创建 和普通Java对象一样，用new在堆上创建，垃圾自动回收，对象被创建之后引用会交给throw。

2.捕获异常

    ①监控区域（guarded region）是一段可能产生异常的代码块（try块），

    ②栈轨迹 可利用printStackTrace打印调用序列用来分析问题；

    ③重新抛出异常 可以把捕获到的异常重新抛出，也可以调用fillInStackTrace方法更新抛出点信息；

    ④异常链 Throwable子类在构造器中可以接受一个cause作为参数，通过把原始异常传递给新的异常，即使在当前位置创建并抛出了新的异常，也能通过这个异常链追踪到异常发生的最初位置。

    ⑤使用finally进行清理 把除了内存之外资源恢复到它们的初始状态时，这类操作通常包括：已打开的文件或网络等；

3.自定义异常 Java自带的异常类型不可能包括所遇到的全部问题，可以自己定义异常类。自定义的异常类必须从已有的异常类进行继承。

4.异常限制

①当覆盖方法时，只能抛出基类方法的异常说明里列出的那些异常，也可以不抛出任何异常；

②异常限制对构造器不起作用，可以抛出声明之外的异常，并且派生类构造器不能捕获基类构造器抛出的异常；

③异常说明本身并不属于方法类型的一部分，不能基于异常说明来重载方法；

④对于在构造阶段可能会抛出异常，并且要求清理的类，最安全的使用方式是使用嵌套的Try子句；

⑤抛出异常的时候，异常处理系统会按照代码书写顺序找出最近的处理程序，匹配的时候并不要求抛出的异常同处理程序所声明的异常完全匹配，派生类的对象也可以匹配其基类的处理程序。

二、Java标准异常类

Error错误：JVM内部的严重问题，无法恢复；

Exception异常：普通异常，通过合理的处理，程序还可以回到正常执行流程，包括受检异常和非受检异常。

三、天瑞地安Java开发规范异常部分

    1.【强制】Java 类库中定义的一类RuntimeException可以通过预先检查进行规避，而不应该通过catch 来处理，比如：IndexOutOfBoundsException，NullPointerException等等；

    2.【强制】异常不要用来做流程控制，条件控制，因为异常的处理效率比条件分支低；

    3.【强制】对大段代码进行try-catch是不负责任的表现。catch时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码，对于非稳定代码的catch尽可能进行区分异常类型，再做对应的异常处理；

    4.【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容；

    5.【强制】有try块放到了事务代码中，catch异常后，如果需要回滚事务，一定要注意手动回滚事务；

    6.【强制】finally块必须对资源对象、流对象进行关闭，有异常也要做try-catch。如果JDK7以上，可以使用try-with-resources方式；

    7.【强制】不能在finally块中使用return，finally块中的return返回后方法结束执行，不会再执行try块中的return语句；

    8.【强制】捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。 说明：如果预期对方抛的是绣球，实际接到的是铅球，就会产生意外情况；

    9.【推荐】方法的返回值可以为null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回null值。调用方需要进行null判断防止NPE问题；

    10.【推荐】防止NPE是程序员的基本修养。NPE产生的场景：①返回类型为包装数据类型，有可能是null，返回int值时注意判空；②数据库的查询结果可能为null；③集合里的元素即使isNotEmpty，取出的数据元素也可能为null；④远程调用返回对象，一律要求进行NPE判断；⑤对于Session中获取的数据，建议NPE检查避免空指针；⑥级联调用obj.getA.getB.getC易产生NPE；

    11.【推荐】在代码中使用“抛异常”还是“返回错误码”，对于公司外的http/api开放接口必须使用“错误码”，而应用内部推荐异常抛出；跨应用间RPC调用优先考虑使用Result方式，封装isSuccess、“错误码”、“错误简短信息”；

    12.【推荐】定义时区分unchecked / checked 异常，避免直接使用RuntimeException抛出，更不允许抛出Exception或者Throwable，应使用有业务含义的自定义异常。推荐业界已定义过的自定义异常，如DAOException/ ServiceException等；

    13.【参考】避免出现重复的代码（Don’t RepeatYourself），即DRY原则。 说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是共用模块。

    天瑞地安“抽疯”程序猿最后总结：尽管异常通常被认为是一种工具，使得你可以在执行过程中报告错误，并从错误中恢复，但是所谓的恢复聊胜于无，不过报告功能室异常的精髓所在，Java坚定地强调所有错误都以异常形式报告这一事实，正是它远远超过异常的精髓所在。既然程序会出问题，主要是开发人员开发忽略了一些关键点，如果没有正确合理的使用异常，并且留下相应的日志，在解决问题的时候就不能发现错误根源，也就不能快速解决问题，生产环境尤为重要！