SSH异常和日志处理方案.docx

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页面 $exception.message 4. 自定义应用异常 异常名称 说明 com.yixun.police.exception.BasicException 基础异常类，本系统中所有的自定义异常类均需继承本类 com.yixun.police.exception. DuplicateKeyException 主键冲突异常，继承BasicException 例： Userinfo save方法异常处理 Override public 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, 比如服务器忙，而不是SocketTimeOutExceotion等 总之，大部分异常我们都可以预先捕获的。那些我们程序的bug,由于各种原因没有捕获，比如空指针，必须用errorPage进行最后的处理。 不能让用户认为我们系统出了什么大问题了。1、利用web应用的error-page可以处理 个人感觉这个方式不好，很显然不好统一定制。 2、利用struts的global-exception好像也可以处理 还可以，简单的应用可以试试 3、hibernate是不是对异常进行了封装或者也有自己的处理机制 对你来说没影响，可以不管他，有封装，但是好像没处理机制 3、spring中aop的afterThrowing可以捕获并记录异常 推荐记录，记录后利用异常链继续向上抛runtime非必捕获异常 4、捕获到的异常是不是最原始的异常信息，还是经过封装的？ 跟异常链有关，一般java新手写的程序95%断链，开源框架的异常可以追溯到原始的信息 5、aop处理异常对性能影响如何？如果架构中使用了缓存机制，是否会有影响？ 异常的捕获确实有性能影响的，个人感觉影响不大，比较异常是偶然发生的。 你指的缓存不明白如何影响异常的捕获 6、是不是需要处理异常，抛出自定义的异常？ 当一