异常处理的规则

 

本文收藏自网络

 

1、  只记录技术上的异常，不记录用户异常

 

 

 

像“用户名已存在”这种异常是不用记录的，但是你需要把它们展示给用户。你需要记录的是类似“磁盘已满”这种技术上的异常，并对这些异常进行相应的处理。如果你把所有的异常都记录到你的日志中，那么你会因为有太多的异常记录，而无法对你日志文件中的异常做出有效处理。你需要研究日志文件中的每一个异常，猜测造成它的原因（“这是个bug吗？”）。太多的异常会让你对日志文件中的日志形成一种草率的心态（“啊哈，不就是个异常嘛”）

 

 

 

2、  在你的异常类中存储数据以便于日志记录

 

 

 

比如说，“不能从账户中取钱”这个异常，你应该像junit那样（“excepted but got …”）去记录异常信息，以便于调试。

 

 

 

CannotChargeMoneyAccountException(Money moneyInAccount, Money toCharge, Account account)

 

 

 

提示信息可以是：“视图从账户‘1234’中取20欧元，但是仅有10欧元可用”。相比“取钱失败”，这样做使得用针对性的方式来处理异常变得更加简单

 

 

 

3、  记录异常的详细描述

 

 

 

JDK中有一个非常负面的例子：ClassCastException长久以来就没有告诉你要把一个对象转型成什么类时发生的异常。

 

 

 

现在它甚至检测了：

 

 

 

final String s = "Hello";

final int x = (Integer) s;

 

 

然后告诉你：

 

T.java:4: inconvertible types

found   : java.lang.String

required: java.lang.Integer

          final Integer x = (Integer) s

 

 

现在运行时java抛出的异常如下：

 

 

 

Exception in thread "main" java.lang.ClassCastException:

java.lang.String cannot be cast to java.lang.Integer

 

比以前好多了。

 

4、 输出所有导致异常发生的原因

 

如果你的异常是一个封装了诱因的异常，那么在异常中记录所有的诱因。有些日志框架已经为你做了这些，而有些却没有。一定要在你的日志文件中记录所有的原因。

 

5、 按正确的级别记录

 

假设你的异常是致命的，那么以Level.Critical级别来记录。你需要自己定义致命对于你来说意味着什么（很多时候它意味着钱少了）。

比如说，假设一个功能不起作用了，或者因为技术问题一个用户不能注册了，这时就有一个致命的问题需要你去解决了。

 

 

 

为致命问题监控日志文件，你的钱正在流失。

 

 

 

实现isCritical()方法的异常类或者一个CriticalException接口，然后检测记录异常时是否按正确的级别进行记录。如果你的日志框架中没有合适的级别，生成一个

 

 

 

6、  不要记录后又抛出一个异常

 

 

 

记录日志又抛出一个异常是异常反面模式（注：就是反面教材的模式）

 

 

 

catch (NoUserException e) {

  LOG.error("No user available", e);

  throw new UserServiceException("No user available", e);

}

 

 

不要这样做。不然你的日志文件中会对同一个异常在不同的堆栈记录几次。只记录一次异常。

 

 

 

7、 不要用System.out or System.err来记录日志

 

 

 

使用日志框架，它能比你更好的处理记录日志。