一.什么是异常
简而言之，程序运行时产生的不正常现象。也就是说程序正常运行是没有异常的。那些情况下 会出现呢？
以实际开发为例，造成的原因为:逻辑原因 、环境原因。例如:
1) int a=0; int b=1/a; ArithmeticException 逻辑原因
2) new File("c:\\a.txt").getXXX(); FileNotFoundException 逻辑原因
3) client.connet();SocketTimeoutException 环境原因 服务器不能及时响应
二.异常分类
1)checked exceptions :
The class Exception and any subclasses that are not also subclasses of RuntimeException are checked exceptions. Checked exceptions need to be declared in a method or constructor's throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary.
2)unchecked exceptions:
RuntimeException and its subclasses are unchecked exceptions. Unchecked exceptions do not need to be declared in a method or constructor's throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary.
（看下面）
分清楚以上两点很重要。
即所有的RuntimeException(运行时异常) 是unchecked异常，其他的异常是 checked(编译时)异常。
在Spring中只有遇到unchecked exceptions事物才会起作用。
三.throw or try...catch(重点)
1) DAO层异常
2) Service层异常
3) Controller层异常
#以某订单系统异常处理为例：暂时不做自定义的异常。
1.目前我们使用Mybatis 框架，所有Dao 层异常自动抛出。
2.因为service 层控制事物。分两种情况：
#---该方法如果受事物控制，必须抛出UncheckedException。例如
@Transactional
public int dataAccessCode(){
try{
..some code that throws SQLException
}catch(SQLException ex){
// ex 中应该给出有意义的信息：例如 订单不存在等。
throw new RuntimeException(ex);
}
}
#---该方法如果不受事物控制，可抛出。如果捕获，则必须让调用者知道该异常。添加注释@throws
#---如果捕获后抛出异常，则必须能够追踪到该异常发生的方法。
3.controller 层。
#---显示处理所有 checked 和 抛出的 unchecked 异常。
#---如果前台页面需要知晓不同的 异常信息，则分别处理异常，否则不予处理。
4.其他RuntimeException：日志会自动记录，然后处理。
四.自定义异常和业务是相关的，考虑是否具有足够的能力设计所有业务异常并使用。
五.日志
#日志处理：分为系统日志和业务日志
以test为例：
1)系统日志:
test.log 为总日志，即处理所有异常的总日志文件(无名logger)。
Logger logger = Logger.getLogger(XXX.Class);
所有的调试日志：一律 设为DEBUG级别。 logger.debug。上线时，test 级别为INFO忽略。
另外，所有error信息，会配置邮件发送功能。处理错误和异常。
2)业务日志：
所有业务日志必须是INFO级别。如果业务确有需要记录日志，应当提出。后期业务日志会备份。
SMS.log 为短信专用日志
pay.log 支付记录日志。
参考文档：
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
Best Practices for Designing the API
1. When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"
2. Preserve encapsulation.
3. Try not to create new custom exceptions if they do not have useful information for client code.
4. Document exceptions.
Best Practices for Using Exceptions
1. Always clean up after yourself
2. Never use exceptions for flow control
3. Do not suppress or ignore exceptions
4. Do not catch top-level exceptions
5. Log exceptions just once
