j2ee框架异常的解决方法struts2+srping+hibernate+freemark+lucence+jsp,

Question

做了几个web项目了但是对exception没有一个标准的写法，欢迎大家讨论下

Answer 1

这是我之前收集整理的

异常设计原则（Effective Java）：
只为异常条件使用异常。也就是说，不要为控制流使用异常，比如，在调用 Iterator.next() 时而不是在第一次检查Iterator.hasNext() 时捕获 NoSuchElementException 。
为可恢复的条件使用检查型异常，为编程错误使用运行时异常。这里，Bloch 回应传统的 Sun 观点 —— 运行时异常应该只是用于指示编程错误，例如违反前置条件。
避免不必要的使用检查型异常。换句话说，对于调用者不可能从其中恢复的情形，或者惟一可以预见的响应将是程序退出，则不要使用检查型异常。
抛出与抽象相适应的异常。换句话说，一个方法所抛出的异常应该在一个抽象层次上定义，该抽象层次与该方法做什么相一致，而不一定与方法的底层实现细节相一致。例如，一个从文件、数据库或者 JNDI 装载资源的方法在不能找到资源时，应该抛出某种 ResourceNotFound 异常（通常使用异常链来保存隐含的原因），而不是更底层的 IOException 、 SQLException 或者 NamingException 。

到底选择检查异常还是非检查异常？？？

1、检查型异常代表关于一个合法指定的请求的操作的有用信息，调用者可能已经对该操作没有控制，并且调用者需要得到有关的通知 —— 例如，文件系统已满，或者远端已经关闭连接，或者访问权限不允许该动作。 

2、非检查异常一般是由程序逻辑错误引起的，程序应该从逻辑角度尽可能避免这类异常的发生。 如果是RuntimeException一般是”你“的问题。

Rod Johnson（spring之父）观点

          检查异常缺点：太多代码，难以读懂的代码、异常的无休止封装、易毁坏的方法签名、检查异常对接口不一定管用（可恢复及不可恢复）。
检查异常要比错误返回码好的多。如果调用代码能对异常做些切合实际的事情，请使用检查异常，如果致命的，或者调用者捕捉它没什么益处，请使用非检查异常。
在包级别决定每个包将怎样使用检查或非检查异常。用文字详细说明非检查异常的决定，因为许多开发人员将预料不到该决定。

使用非检查异常的唯一危险是那些异常可能没有被充分用文字加以详细说明。详细的异常说明。

这是iteye很早之前讨论的
[url]http://www.iteye.com/topic/2038?page=12[/url]
[url]http://www.iteye.com/topic/72170[/url]