ssh异常和日志处理方案

《ssh异常和日志处理方案》由会员分享，可在线阅读，更多相关《ssh异常和日志处理方案（5页珍藏版）》请在金锄头文库上搜索。

1、1 异常和日志的作用 1.1. 异常的作用 Java 异常机制是为了对程序中可能出现的已知错误进行捕获，并进行相应处理。从是否反馈给用户来看，存在两类异常： 系统异常：这类异常由系统本身的低级异常引起，例如数据库连接失败、内存溢出、空指针异常等等，这类异常不需要出现在前台，因为用户看不懂也没有必要看到这些异常信息。这类异常需要在日志中进行完整记录以供日后开发人员进行查看分析。 应用异常：即自定义异常，这类异常需要通过前台反馈给用户，友好提示用户当前操作异常。应用异常通过系统异常转换而来，例如新建用户时，发生“主键冲突异常” ，则需要在UserinfoDao 中将 “主键冲突异常”捕获，并转换为

2、应用异常，异常提示信息设为“该用户名 XXX 已存在，请使用其它用户名” ，并将该异常信息反馈给前台。只要系统异常影响到的用户的当前操作，就必须给用户提示信息，比如“系统后台发生错误，请稍后再试”等。应用异常应按照提示方式的异常进行分类，对应不同的提示页面。 1.2. 日志的作用 系统运行日志：记录系统的运行情况，跟踪代码运行时轨迹； 异常和错误日志：记录异常堆栈信息，以供开发人员查看分析； 业务日志：记录业务信息和用户操作，例如用户登录、删除数据、更新数据等。 2. 异常的处理原则 1、避免过大的 try 块，不要把不会出现异常的代码放到 try 块里面，尽量保持一个 try 块对应一个或多

3、个异常。 2、细化异常的类型，不要不管什么类型的异常都写成 Excetpion。catch 语句表示我们预期会出现某种异常，而且希望能够处理该异常。异常类的作用就是告诉 Java 编译器我们想要处理的是哪一种异常，然后针对具体的异常类进行不同的处理。例如在 DAO 层中我们应该只捕获 SQLException 或 DataAccessException(Spring 自定义的数据访问异常类 )这些数据库异常类，其他的异常 NullPointException、NumberFormatException 等应通过检测代码增加其健壮性来解决，而不应该通过 try.catch(Exception e

4、)语句捕获所有的异常。 3、不要把自己能处理的异常抛给别人，不要忽略捕获的异常，捕获到后要么处理，要么转译，要么重新抛出新类型的异常。 。处理方式包括： 处理异常。针对该异常采取一些行动，例如修正问题、提醒某个人或进行其他一些处理，要根据具体的情形确定应该采取的动作。再次说明，调用 printStackTrace 算不上已经“处理好了异常” 。 重新抛出异常。处理异常的代码在分析异常之后，认为自己不能处理它，重新抛出异常也不失为一种选择。 把该异常转换成另一种异常。大多数情况下，这是指把一个低级的异常转换成应用级的异常（其含义更容易被用户了解的异常） 。 4、如果对 catch 块尽量保持一个

5、块捕获一类异常，在 catch 语句中尽可能指定具体的异常类型，必要时使用多个 catch。 例： try catch (Exception e) e.printStackTrace(); log.error(UserinfoDao execute() failed); 这段代码捕获了异常，但实际上对异常并没有进行处理，可以算得上 Java 编程中的杀手。按照这个方式，在 DAO 层发生异常被忽略，Service 层就认为 DAO 层运行正确，就不会回滚，事务控制就没有任何作用！ printStackTrace 对调试程序有帮助，但程序调试阶段结束之后，printStackTrace 就不应再

6、在异常处理模块中担负主要责任。 日志尽量在系统中的各个出口，例如 Action、调度方法等处统一记录，可减少工作量，况且日志UserinfoDao execute() failed”并没有说明异常的详细信息，没有必要向日志输出这句话。 即使 catch 中加入 throw new RuntimeException(e);语句。如果捕获的异常是RuntimeException，更没有必要将异常再次转化为 RuntimeException，这样不仅异常的本身的类型丢失，重新定义异常也造成一定消耗。 所以该处的处理原则应是：如果该处异常需要能转化为业务异常反馈给用户，则需要捕捉低级异常并转换成业务异

7、常上抛，否则不做任佧行过过程中产生com.yixun.police.exception.BasicException 异常，则会自动转到 basicerror 页面，从而给用户相应的提示。 basicerror 页面 $exception.message 4. 自定义应用异常 异常名称 说明 com.yixun.police.exception.BasicException 基础异常类，本系统中所有的自定义异常类均需继承本类 com.yixun.police.exception. DuplicateKeyException 主键冲突异常，继承BasicException 例： Userinfo

8、 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 DuplicateKeyExc

9、eption(用户名:+entity.getUserid()+已存在，请使用其他用户名); 5. 日志配置 系统中目前配置了三个日志记录器，一个为异常记录器，专门记录异常信息，日志文件到达一定大小后将产生新的日志文件，文件名称为 exception.log，另一个为系统运行记录器，按照日期记录所有的日志信息。在 SSH 架构中出现异常时 1、要进行捕获且展现友好的信息给用户 2、要记录出现的异常供维护人员回溯问题 想到的几个点 1、利用 web 应用的 error-page 可以处理 2、利用 struts 的 global-exception 好像也可以处理 3、hibernate 是不是对

10、异常进行了封装或者也有自己的处理机制 3、spring 中 aop 的 afterThrowing 可以捕获并记录异常 4、捕获到的异常是不是最原始的异常信息，还是经过封装的？ 5、aop 处理异常对性能影响如何？如果架构中使用了缓存机制，是否会有影响？ 6、是不是需要处理异常，抛出自定义的异常？ 7、ajax 方式，后台异常如何处理？SSH 异常 解决 方案 总结 1.对一个需要提供稳定、高质量的 WEB 系统而言， 对整个 WEB 程序的入口、出口的异常处理都需要做封装。 2.Logic、DAO 可以根据需要，向上层抛出相应的 Exception， 而这些 Exception 都必须在 A

11、ction 截住，也就是封装起来，向 View 返回一个合适的信息。 3.发生异常之后，返回到 View 的信息，可以是给人看得 HTML 也可以是给 JavaScript 看的JSON， 所以，普通页面的异常，可以显示错误页面；Ajax 发生的异常，可以返回一个包容错误信息的JSON，让 Ajax 显示出来。 4.很多异常处理是在设计阶段就可以预见的，不要用 Spring 的 AOP 拦截，这样会对系统性能操成恶性的影响。 可以做一个 BaseAction，把共通的处理写在里面。 5.具体的，抛出、捕获什么样的异常信息，根据系统实际处理内容确定。 根据不同的异常，可以让接收方程序作相应的处理

12、不局限于错误处理。能捕获的可控制的异常，就不要让用户知道太多细节。可以改成一些客户能理解的信息。 比如网络连接中断，而不是 IOException, 比如服务器忙，而不是SocketTimeOutExceotion 等 总之，大部分异常我们都可以预先捕获的。那些我们程序的 bug,由于各种原因没有捕获，比如空指针，必须用 errorPage 进行最后的处理。 不能让用户认为我们系统出了什么大问题了。1、利用 web 应用的 error-page 可以处理 个人感觉这个方式不好，很显然不好统一定制。 2、利用 struts 的 global-exception 好像也可以处理 还可以，简单的应用

13、可以试试 3、hibernate 是不是对异常进行了封装或者也有自己的处理机制 对你来说没影响，可以不管他，有封装，但是好像没处理机制 3、spring 中 aop 的 afterThrowing 可以捕获并记录异常 推荐记录，记录后利用异常链继续向上抛 runtime 非必捕获异常 4、捕获到的异常是不是最原始的异常信息，还是经过封装的？ 跟异常链有关，一般 java 新手写的程序 95%断链，开源框架的异常可以追溯到原始的信息 5、aop 处理异常对性能影响如何？如果架构中使用了缓存机制，是否会有影响？ 异常的捕获确实有性能影响的，个人感觉影响不大，比较异常是偶然发生的。 你指的缓存不明白如何影响异常的捕获 6、是不是需要处理异常，抛出自定义的异常？ 当一段代码抛异常的时候，你要看你能不能在 catch 块内修复程序，让程序继续走不会出问题，否则不建议 catch 业务系统比较大的话可以自己模仿开源框架那样定义业务异常，和逻辑异常。方便逻辑判断例如使用 instanceof 7、ajax 方式，后台异常如何处理？ 向上抛，或者在 jsp 中发现异常，然后 throw 出来，直到 jsb 报红叉为止，否则 ajax 判断的状态码永远是对的。 在有一个地方可以捕获异常，过滤器。