首先是一个要不要用checked Exeption的一个讨论
[url]http://www.iteye.com/topic/2038[/url]
总结得出的基本原则:
[quote]使用Checked Exception还是UnChecked Exception的原则,我的看法是根据需求而定。
如果你希望强制你的类调用者来处理异常,那么就用Checked Exception;
如果你不希望强制你的类调用者来处理异常,就用UnChecked。
那么究竟强制还是不强制,权衡的依据在于从业务系统的逻辑规则来考虑,如果业务规则定义了调用者应该处理,那么就必须Checked,如果业务规则没有定义,就应该用UnChecked。
还是拿用户登陆的例子来说,
User login(String username, String password); throws UserNotFoundException, PasswordNotMatchException;
try {
UserManager.login(xx,xx);;
....
用户登陆以后的主事件流代码
} catch (UserNotFoundException e); {
...
用户名称没有的事件处理,例如产生一个提示用户注册的页面
} catch (PasswordNotMatchException e); {
....
密码不对的事件处理,例如forward到重新登陆的页面
}
可能产生的异常有:
IOException (例如读取配置文件找不到)
SQLException (例如连接数据库错误)
ClassNotFoundException(找不到数据库驱动类)
NoSuchUserException
PasswordNotMatchException
以上3个异常是和业务逻辑无关的系统容错异常,所以应该转换为RuntimeException,不强制类调用者来处理;而下面两个异常是和业务逻辑相关的流程,从业务实现的角度来说,类调用者必须处理,所以要Checked,强迫调用者去处理。
在这里将用户验证和密码验证转化为方法返回值是一个非常糟糕的设计,不但不能够有效的标示业务逻辑的各种流程,而且失去了强制类调用者去处理的安全保障。
至于类调用者catch到NoSuchUserException和PasswordNotMatchException怎么处理,也要根据他自 己具体的业务逻辑了。或者他有能力也应该处理,就自己处理掉了;或者他不关心这个异常,也不希望上面的类调用者关心,就转化为 RuntimeException;或者他希望上面的类调用者处理,而不是自己处理,就转化为本层的异常继续往上抛出来。
[/quote]
[b]An Exception Handling Framework for J2EE Applications[/b]
[url]http://onjava.com/pub/a/onjava/2006/01/11/exception-handling-framework-for-j2ee.html?page=6[/url]
附件为源码
[url]http://www.iteye.com/topic/2038[/url]
总结得出的基本原则:
[quote]使用Checked Exception还是UnChecked Exception的原则,我的看法是根据需求而定。
如果你希望强制你的类调用者来处理异常,那么就用Checked Exception;
如果你不希望强制你的类调用者来处理异常,就用UnChecked。
那么究竟强制还是不强制,权衡的依据在于从业务系统的逻辑规则来考虑,如果业务规则定义了调用者应该处理,那么就必须Checked,如果业务规则没有定义,就应该用UnChecked。
还是拿用户登陆的例子来说,
User login(String username, String password); throws UserNotFoundException, PasswordNotMatchException;
try {
UserManager.login(xx,xx);;
....
用户登陆以后的主事件流代码
} catch (UserNotFoundException e); {
...
用户名称没有的事件处理,例如产生一个提示用户注册的页面
} catch (PasswordNotMatchException e); {
....
密码不对的事件处理,例如forward到重新登陆的页面
}
可能产生的异常有:
IOException (例如读取配置文件找不到)
SQLException (例如连接数据库错误)
ClassNotFoundException(找不到数据库驱动类)
NoSuchUserException
PasswordNotMatchException
以上3个异常是和业务逻辑无关的系统容错异常,所以应该转换为RuntimeException,不强制类调用者来处理;而下面两个异常是和业务逻辑相关的流程,从业务实现的角度来说,类调用者必须处理,所以要Checked,强迫调用者去处理。
在这里将用户验证和密码验证转化为方法返回值是一个非常糟糕的设计,不但不能够有效的标示业务逻辑的各种流程,而且失去了强制类调用者去处理的安全保障。
至于类调用者catch到NoSuchUserException和PasswordNotMatchException怎么处理,也要根据他自 己具体的业务逻辑了。或者他有能力也应该处理,就自己处理掉了;或者他不关心这个异常,也不希望上面的类调用者关心,就转化为 RuntimeException;或者他希望上面的类调用者处理,而不是自己处理,就转化为本层的异常继续往上抛出来。
[/quote]
[b]An Exception Handling Framework for J2EE Applications[/b]
[url]http://onjava.com/pub/a/onjava/2006/01/11/exception-handling-framework-for-j2ee.html?page=6[/url]
附件为源码