J2ee的异常处理

一种观点：

一、发生异常时，应该给用户一个明确的提示，告诉用户错误原因，应该如何操作。

从用户角度考虑，我把异常分为以下几种：
1、用户异常： 相当于业务异常，如用户输入密码错误，则throw new BussinessException("密码输入错误，请重试");
2、代码异常：如程序员疏忽，导致代码抛出NullException。这类异常对于用户来说，没办法作出回应。用户只能找管理员解决这个问题。所以这类异常可以定义为："您的操作服务器无法响应，请联系管理员";
3、其他的可以为外界环境导致的异常，如数据库无法连接等，这类异常对于用户来说一样没办法。

二、异常框架的搭建提以下几点：
1、捕获底层异常，转为自定义的异常。如SQLException，由DAO捕获，并且抛出DaoException。这里的SQLException为底层异常
2、自定义异常一般继承RuntimeException，这样无需再接口上声明。
3、出现底层异常立即捕获，自定义异常让后台最上层代码处理。如web应用可以由action的基类或者filter统一处理异常，抛给用户。
4、业务异常可以命名的更有意义，如UserNotFoundException。我比较偷懒，一般直接抛出BussinessException


--------------------

你是如何处理捕获的异常的？
捕获了异常却不作任何处理，可以算得上Java编程中的杀手。从问题出现的频繁程度和祸害程度来看，它也许可以和C/C++程序的一个恶名远播的问题相提并论??不检查缓冲区是否已满。如果你看到了这种丢弃（而不是抛出）异常的情况，可以百分之九十九地肯定代码存在问题。
错误在于，异常总是意味着某些事情不对劲了，或者说至少发生了某些不寻常的事情，我们不应该对程序发出的求救信号保持沉默和无动于衷。调用一下printStackTrace算不上"处理异常"。不错，调用printStackTrace对调试程序有帮助，但程序调试阶段结束之后，printStackTrace就不应再在异常处理模块中担负主要责任了。
那么，应该怎样改正呢？主要有四个选择：

　　1、处理异常。针对该异常采取一些行动，例如修正问题、提醒某个人或进行其他一些处理，要根据具体的情形确定应该采取的动作。再次说明，调用printStackTrace算不上已经"处理好了异常"。

　　2、重新抛出异常。处理异常的代码在分析异常之后，认为自己不能处理它，重新抛出异常也不失为一种选择。

　　3、把该异常转换成另一种异常。大多数情况下，这是指把一个低级的异常转换成应用级的异常（其含义更容易被用户了解的异常）。

　　4、不要捕获异常。