SSH异常和日志处理方案

1 异常和日志的作用1.1. 异常的作用Java异常机制是为了对程序中可能出现的已知错误进行捕获，并进行相应处理。

从是否反馈给用户来看，存在两类异常：系统异常：这类异常由系统本身的低级异常引起，例如数据库连接失败、内存溢出、空指针异常等等，这类异常不需要出现在前台，因为用户看不懂也没有必要看到这些异常信息。

这类异常需要在日志中进行完整记录以供日后开发人员进行查看分析。

应用异常：即自定义异常，这类异常需要通过前台反馈给用户，友好提示用户当前操作异常。

应用异常通过系统异常转换而来，例如新建用户时，发生“主键冲突异常”，则需要在UserinfoDao中将“主键冲突异常”捕获，并转换为应用异常，异常提示信息设为“该用户名XXX已存在，请使用其它用户名”，并将该异常信息反馈给前台。

只要系统异常影响到的用户的当前操作，就必须给用户提示信息，比如“系统后台发生错误，请稍后再试”等。

应用异常应按照提示方式的异常进行分类，对应不同的提示页面。

1.2. 日志的作用系统运行日志：记录系统的运行情况，跟踪代码运行时轨迹；异常和错误日志：记录异常堆栈信息，以供开发人员查看分析；业务日志：记录业务信息和用户操作，例如用户登录、删除数据、更新数据等。

2. 异常的处理原则1、避免过大的try块，不要把不会出现异常的代码放到try块里面，尽量保持一个try块对应一个或多个异常。

2、细化异常的类型，不要不管什么类型的异常都写成Excetpion。

catch语句表示我们预期会出现某种异常，而且希望能够处理该异常。

异常类的作用就是告诉Java编译器我们想要处理的是哪一种异常，然后针对具体的异常类进行不同的处理。

例如在DAO层中我们应该只捕获SQLException或DataAccessException(Spring自定义的数据访问异常类)这些数据库异常类，其他的异常NullPointException、NumberFormatException等应通过检测代码增加其健壮性来解决，而不应该通过try..catch(Exception e)…语句捕获所有的异常。

3、不要把自己能处理的异常抛给别人，不要忽略捕获的异常，捕获到后要么处理，要么转译，要么重新抛出新类型的异常。

处理方式包括：处理异常。

针对该异常采取一些行动，例如修正问题、提醒某个人或进行其他一些处理，要根据具体的情形确定应该采取的动作。

再次说明，调用printStackTrace算不上已经“处理好了异常”。

重新抛出异常。

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

把该异常转换成另一种异常。

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

4、如果对catch块尽量保持一个块捕获一类异常，在catch语句中尽可能指定具体的异常类型，必要时使用多个catch。

例：try {} catch (Exception e) {e.printStackTrace();log.error("UserinfoDao execute() failed");}这段代码捕获了异常，但实际上对异常并没有进行处理，可以算得上Java编程中的杀手。

按照这个方式，在DAO层发生异常被忽略，Service层就认为DAO层运行正确，就不会回滚，事务控制就没有任何作用！！！printStackTrace对调试程序有帮助，但程序调试阶段结束之后，printStackTrace就不应再在异常处理模块中担负主要责任。

日志尽量在系统中的各个出口，例如Action、调度方法等处统一记录，可减少工作量，况且日志"UserinfoDao execute() failed”并没有说明异常的详细信息，没有必要向日志输出这句话。

即使catch中加入throw new RuntimeException(e);语句。

如果捕获的异常是RuntimeException，更没有必要将异常再次转化为RuntimeException，这样不仅异常的本身的类型丢失，重新定义异常也造成一定消耗。

所以该处的处理原则应是：如果该处异常需要能转化为业务异常反馈给用户，则需要捕捉低级异常并转换成业务异常上抛，否则不做任佧行过过程中产生com.yixun.police.exception.BasicException异常，则会自动转到basicerror页面，从而给用户相应的提示。

basicerror页面<%@ page language="java" contentType="text/xml; charset=UTF-8"pageEncoding="UTF-8"%>${exception.message }4. 自定义应用异常异常名称说明com.yixun.police.exception.BasicException 基础异常类，本系统中所有的自定义异常类均需继承本类com.yixun.police.exception. DuplicateKeyException 主键冲突异常，继承BasicException例：Userinfo save方法异常处理@Overridepublic void save(Userinfo entity) {try {super.save(entity);} catch (DataIntegrityViolationException e) {if(e.getCause().getCause() instanceof SQLException){SQLException sqlE = (SQLException)e.getCause().getCause();if(sqlE.getErrorCode()==1){//ORACLE主键冲突异常代码throw new DuplicateKeyException("用户名:"+entity.getUserid()+"已存在，请使用其他用户名");}}}}5. 日志配置系统中目前配置了三个日志记录器，一个为异常记录器，专门记录异常信息，日志文件到达一定大小后将产生新的日志文件，文件名称为exception.log，另一个为系统运行记录器，按照日期记录所有的日志信息。

在SSH架构中出现异常时1、要进行捕获且展现友好的信息给用户2、要记录出现的异常供维护人员回溯问题想到的几个点1、利用web应用的error-page可以处理2、利用struts的global-exception好像也可以处理3、hibernate是不是对异常进行了封装或者也有自己的处理机制3、spring中aop的afterThrowing可以捕获并记录异常4、捕获到的异常是不是最原始的异常信息，还是经过封装的？5、aop处理异常对性能影响如何？如果架构中使用了缓存机制，是否会有影响？6、是不是需要处理异常，抛出自定义的异常？7、ajax方式，后台异常如何处理？SSH 异常解决方案总结1.对一个需要提供稳定、高质量的WEB系统而言，对整个WEB程序的入口、出口的异常处理都需要做封装。

2.Logic、DAO可以根据需要，向上层抛出相应的Exception，而这些Exception都必须在Action截住，也就是封装起来，向View返回一个合适的信息。

3.发生异常之后，返回到View的信息，可以是给人看得HTML也可以是给JavaScript看的JSON，所以，普通页面的异常，可以显示错误页面；Ajax发生的异常，可以返回一个包容错误信息的JSON，让Ajax显示出来。

4.很多异常处理是在设计阶段就可以预见的，不要用Spring的AOP拦截，这样会对系统性能操成恶性的影响。

可以做一个BaseAction，把共通的处理写在里面。

5.具体的，抛出、捕获什么样的异常信息，根据系统实际处理内容确定。

根据不同的异常，可以让接收方程序作相应的处理——不局限于错误处理。

能捕获的可控制的异常，就不要让用户知道太多细节。

可以改成一些客户能理解的信息。

比如网络连接中断，而不是IOException, 比如服务器忙，而不是SocketTim eOutExceotion 等总之，大部分异常我们都可以预先捕获的。

那些我们程序的bug,由于各种原因没有捕获，比如空指针，必须用errorPage进行最后的处理。

不能让用户认为我们系统出了什么大问题了。

1、利用web应用的error-page可以处理个人感觉这个方式不好，很显然不好统一定制。

2、利用struts的global-exception好像也可以处理还可以，简单的应用可以试试3、hibernate是不是对异常进行了封装或者也有自己的处理机制对你来说没影响，可以不管他，有封装，但是好像没处理机制3、spring中aop的afterThrowing可以捕获并记录异常推荐记录，记录后利用异常链继续向上抛runtime非必捕获异常4、捕获到的异常是不是最原始的异常信息，还是经过封装的？跟异常链有关，一般java新手写的程序95%断链，开源框架的异常可以追溯到原始的信息5、aop处理异常对性能影响如何？如果架构中使用了缓存机制，是否会有影响？异常的捕获确实有性能影响的，个人感觉影响不大，比较异常是偶然发生的。

你指的缓存不明白如何影响异常的捕获6、是不是需要处理异常，抛出自定义的异常？当一段代码抛异常的时候，你要看你能不能在catch块内修复程序，让程序继续走不会出问题，否则不建议catch业务系统比较大的话可以自己模仿开源框架那样定义业务异常，和逻辑异常。

方便逻辑判断例如使用instanceof7、ajax方式，后台异常如何处理？向上抛，或者在jsp中发现异常，然后throw出来，直到jsb报红叉为止，否则ajax判断的状态码永远是对的。

在有一个地方可以捕获异常，过滤器。