java异常及日志注意事项

一、异常注意事项

简单整理了下关于异常的规范：

1)      在异常处理模块中应提供精确、易读的错误原因信息。

2)      不要处理能够避免的异常。

3)      一个方法不应该抛出太多类型的异常，最好不超过三个。

4)      不要在try以及finally字段内部使用return语句。

5)      数据库、io操作等涉及资源池泄漏的操作一定要在finally中来释放资源。

6)      将try/catch区段置于循环之外。

7)      不要将异常用于程序流程控制，异常处理效率低于条件分支，且跳转流程难以预测。

8)      在程序中使用异常处理还是使用错误返回码处理，根据是否有利于程序结构来确定，并且异常和错误码不应该混合使用，推荐使用异常。

9)      异常捕获尽量不要直接catch（Exception），应该把异常细分处理。

10)   对于异常应分类处理，不要只捕捉Exception。

11)   对于异常不能忽略，并且应该记入日志。

二、异常优化

2.1、不要忽略checked Exception

　　1)      处理异常，进行修复以让程序继续执行。例如在进行数据库查询时，数据库连接断链后重新链接成功。

　　2)      在对异常进行分析后发现这里不能处理它，那么重新抛出异常，让调用者处理。异常依次向上抛出，如果所有方法都不能恰当地处理异常，最终会在用户以恰当的方式提示用户，由用户来判断下一步处理措施。例如在进行数据库查询时，断链后重试几次依旧失败的情况。

　　3)      将异常转换为其他异常再抛出，这时应该注意不要丢失原始异常信息。这种情况一般用于将底层异常封装为应用层异常。

　　4)      不要捕获异常，应在函数定义中使用throws声明将抛出该异常，让调用者去处理该异常。

　　5)      因此，当捕获一个checked Exception的时候，必须对异常进行处理；如果认为不必要在这里作处理，就不要捕获该异常，在方法体中声明方法抛出异常，由上层调用者来处理该异常。

2.2、不要捕获unchecked Exception

　　有两种checked Exception：

　　1)　　Error：这种情况属于JVM发生了不可恢复的故障，例如内存溢出，无法处理。

　　2) 　　RuntimeException：这种情况属于错误的编码导致的，出现异常后需要修改代码才能修复，一般来说catch后没有恰当的处理方式，因此不应该捕获。（该规则不适用于守护线程中处理catch runtime exception）

2.3、不要一次捕获所有的异常

　　1)      针对try块中抛出的每种Exception，很可能需要不同的处理和恢复措施，而由于这里只有一个catch块，分别处理就不能实现。

　　2)      Try块中还可能抛出RuntimeException，代码中捕获了所有抛出的RuntimeException而没有做任何处理，掩盖了编程的错误，会导致程序难以调试。

2.4、使用finally块释放资源

　　什么是资源：程序中使用的数量有限的对象，或者只能独占式访问的对象。例如：线程、线程池、数据库连接、ftp连接，因为资源是“有限的“，因此资源使用后必须释放，以避免程序中的资源被耗尽，影响程序运行。某些资源，使用完毕后会自动释放，如线程，某些资源则需要显示释放，如数据库连接。

  　　Finally关键字保证无论程序使用任何方式离开try块，finally中的语句都会执行。

 　　 因此，当你需要一个地方来执行在任何情况下都必须执行的代码时，就可以将这些代码放入到finally块中。当你的程序中使用了资源，如数据库连接，文件，Ftp连接，线程等，必须将示范给这些资源的代码写入finally块中。

2.5、finally块中不能抛出异常

　　JAVA异常处理机制保证无论在任何情况下都先执行finally快的代码，然后再离开整个try,catch,finally块。在try,catch块中向外抛出异常的时候，JAVA虚拟机先转到finally块执行finally中的代码，然后将异常抛出。但如果在finally块中抛出异常，try,catch块的异常就不能抛出，外部捕捉到的异常就是finally块中的异常信息，而try，catch块中发生的真正的异常堆栈信息则丢失了。

2.6、抛出自定义异常时带上原始异常信息

　　Try块捕获抛出的异常后，抛出了新的自定义异常需要将原来异常的堆栈信息带上，利于排错。

2.7、不要同时使用异常机制和返回值来进行异常处理

　　例如：

　　try{

　　　　......

　　}catch(Exception e){

　　　　throw new Exception(msg,e);

　　　　return " ";

　　　}

　　混合使用JAVA异常处理机制和返回值使程序的异常处理部分变得“丑陋不堪”，并难以理解。如果有多种不同的异常情况，就定义多种不同的异常，而不要像上面代码那样综合使用Exception和返回值。

三、日志优化及注意事项

3.1、Log上下文

　　在Log中必须尽量带入上下文的信息，对比以下两个Log信息，后者比前者更有作用。

3.2、Error或者Warn级别中碰到Exception的情况尽量log完整的异常信息

　　Error和Warn级别是比较严重的情况，意味着系统出错或者危险，我们需要更多的信息来帮助分析原因，这个时候越多的信息越有帮助。包含以下内容：

　　1)      你是在做什么事情的时候出错了

　　2)      你是在用什么数据做这个事情的时候出错了

　　3)      出错的信息是什么

　　对比下面三个Log语句，第一个提供了详尽的信息，第二个只提供了部分信息，Exception的Message不一定包含有用的信息，第三个只告诉你出错了，其他的你一无所知：

　　1)      Log.error(“获取用户[{}]的用户信息时出错”,username,ex);

　　2)      Log.error(“获取用户[{}]的用户信息时出错”,username,ex.getMessage());

　　3)     Log.error(“获取用户[{}]的用户信息时出错”);

3.3、基本的Logger编码

　　1)      在一个对象中通常只使用一个Logger对象，Logger应该是static final的，只有在少数需要在构造函数中传递logger的情况下才使用private fianl。

　　Static final Logger logger = LoggerFactory.getLogger(Main.class);

　　2)      输出Exceptions的全部Throwable信息，因为logger.error（msg）和logger.error(msg,e.getMessage())这样的日志输出方法会丢失掉最重要的StackTrace信息。

　　Void foo(){

       　　Try{

　　　　　　......

      　　 }catch(Exception e){

              　　Logger.error(e.getMessage());//错误

              　　Logger.error(“msg”,e.getMessage());//错误

　　　　　　Logger.error(“msg”,e);//正确

      　　 }

　　}

　　3)      对与不是特别重要的异常，不允许记录日志后又抛出异常，因为这样会多次记录日志，只允许记录一次

　　Try{

　　　　......

　　}catch(Exception ex){

　　　　Logger.error(errorMessage,ex);

      　　 Throw new UserSercviceException(errorMessage,ex);

　　}

　　4)      不允许出现System print(包括System.out.println和System.error.println)语句。

　　5)      不允许出现e.printStackTrace。

　　6)      日志性能的考虑，如果代码为核心代码，执行频率非常高，则输出日志建议增加判断，尤其是低级别的输出<debug、info、warn>。

　　7)      有意义的日志

　　　　通常情况下在程序日志里记录一些比较有意义的状态数据：程序启动，退出的时间点：

　　　　程序运行消耗时间；耗时程序的执行进度；重要变量的状态变化。

　　　　除此之外，在公共的日志里规避打印程序的调试或者提示信息。

　　说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？