- 浏览: 494626 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (301)
- Swing技术 (1)
- Linux (1)
- Javascript (22)
- 数据结构和算法 (3)
- J2SE (36)
- workflow (5)
- 设计模式 (14)
- web service (19)
- Ajax (14)
- 中间件 & 服务器 (8)
- 多线程 (9)
- Oracle (52)
- sys & soft (10)
- JMS (3)
- sso (9)
- android (11)
- struts2 (10)
- web协议 (2)
- 分布式 (2)
- PM (2)
- OLAP (3)
- Redis (2)
- Hibernate (7)
- ibatis (2)
- SQLServer (1)
- maven (3)
- Spring (7)
- Jsp (2)
- slf4j (1)
- jQuery (15)
- 权限 (1)
- 系统集成 (1)
- 笔记 (1)
- Freemarker (2)
- 项目管理 (1)
- eclipse (3)
- GIS (1)
- NoSql (3)
- win10 (1)
- win10网络 (2)
- 底层 (3)
- 数据库 (0)
最新评论
-
kabuto_v:
请问那种图,uml图是怎么画出来的呢?是您自己手工画的,还是有 ...
FastJSON 序列化、反序列化实现 -
梦行Monxin商城系统:
电商实例、业务并发、网站并发及解决方法 -
rockethj8:
client 㓟有一个参数是可以忽略一些URL 不进行验证登录 ...
SSO 之 (单点登录)实施中遇到的几个问题 -
mengxiangfeiyan:
好啊。。。。。
Oracle删除表,删除数据以及恢复数据、利用现有表创建新表
J2EE系统异常的处理准则
异常的处理是每个Java程序员时常面对的问题,但是很多人没有原则,遇到异常也不知道如何去处理,于是遇到检查异常就胡乱try...catch...一把,然后e.printStackTrace()一下了事,这种做法通常除了调试排错有点作用外,没任何价值。对于运行时异常,则干脆置之不理。
原因是很多开发者缺乏对异常的认识和分析,首先应该明白Java异常体系结构,一种分层继承的关系,你必须对层次结构熟烂于心:
Throwable(必须检查)
Error(非必须检查)
Exception(必须检查)
RuntimeException(非必须检查)
一般把Exception异常及其直接子类(除了RuntimeException之外)的异常称之为检查异常。把RuntimeException以及其子类的异常称之为非检查异常,也叫运行时异常。
对于Throwable和Error,则用的很少,一般会用在一些基础框架中,这里不做讨论。
下面针对J2EE的分层架构:DAO层、业务层、控制层、展示层的异常处理做个分析,并给出一般处理准则。
一、DAO层异常处理
如果你用了Spring的DAO模板来实现,则DAO层没有检查异常抛出,代码非常的优雅。但是,如果你的DAO采用了原始的JDBC来写,这时候,你不能不对异常做处理了,因为难以避免的SQLException会如影随形的跟着你。对已这种DAO级别的异常,异常了你又能如何呢?与其这样胡乱try...catch...,囫囵吞枣消灭了异常不如让异常以另外一种非检查的方式向外传递。这样做好处有二:
1)、DAO的接口不被异常所污染,假设你抛出了SQLException,以后要是换了Spring DAO模板,那DAO接口就不再抛出了SQLException,这样,你的接口抛出异常就是对接口的污染。
2)、DAO异常向外传播给更高层处理,以便异常的错误原因不丢失,便于排查错误或进行捕获处理。
这里还有一个设计上常常令人困扰的问题:很多人会问,那定义一个什么样的异常抛出呢,或者是直接抛出一个throw RuntimeException(e)? 对于这个问题,需要分场合,如果系统小,你可以直接抛出一个throw RuntimeException(e),但对于一个庞大的多模块系统来说,不要抛这种原生的非检查异常,而要抛出自定义的非检查异常,这样不但利于排错,而且有利于系统异常的处理,通常针对每一个模块,粗粒度的定义一个运行时DAO异常。比如:throw new ModelXxxDAORuntimeException(".....",e),对于msg信息,你可写也可不写,根据需要灵活抛出。
这里常见一个很愚昧的处理方式,为每个DAO定义一个异常,呵呵,这样累不累啊,有多大意义,在Service层中调用时候,如果要捕获,还要捕获出一堆异常。这样致命的问题是代码混乱,维护困难,阅读也困难,DAO的异常应该是粗粒度的。
二、业务层异常处理
习惯上把业务层称之为Service层或者服务层,Service层的代表的是业务逻辑,不要迷信分太多太多层有多大好处,除非需要,否则别盲目划分不必要的层,层越多,效率越差,根据需要够用就行了。
Service接口中的每个方法代表一个特定的业务,而这个业务一定是一个完整的业务,通常会看到一些傻X的做法,数据库事务配置在Service层,而Service的实现就是DAO的直接调用,然后在控制层(Action)中,调用了好多Service去完成一个业务,你气得已经无语了,低头找砖头去!!!
搞明白以上两个问题后再回过头看异常怎么处理,Service层通常依赖DAO,而Service层的通常也会因为调用别的非检查异常方法而必须面对异常处理的问题,这里和DAO层又有所不同,彼一时,此一时嘛!
一般来说一个小模块对应一个Service,当然也许有两个或多个,针对这个模块的Service定义一个非检查异常,以应付那些不可避免的异常检查,这个自定义异常可以简单的命名为XxxServiceRuntimeException,将捕获到的异常顺势转译为非检查异常后抛出。我喜欢这么做,因为前台是J2EE应用,前台是web页面,它们的Struts2等框架会自动捕获所有Service层的异常,并把异常交给开发者去自由处理。
但是还有一种情况,由于一些特殊的限制,如果某个异常一旦发生,必须做什么什么处理,而这种处理时硬性要求,或者调用某个Service方法,必须检查处理什么异常,也可以抛出非检查的自定义异常,往往出现这种情况的是政治原因。不推崇这种做法,但也不排斥。
总之,对于接口,尽可能不去用异常污染她!
三、控制层异常
控制层说的简单些就是常见的Action层,主要是控制页面请求的处理。控制层通常都依赖于Service层,现在比较流行的框架对控制层做得都相当的到位,比如Struts2、SpringMVC等等,他们的控制层框架会捕获业务层的所有异常,并在控制层中声明可能抛出Exception,因此控制层一般不处理什么异常。
如果是控制层中因为调用了一些非检查异常的方法,比如IO操作等,可以简单处理下异常,保证流的安全,这才是目的。
四、显示层异常处理
对于页面异常,处理的方式多种多样,一是不处理异常,一旦异常了,页面就报错。二是定义出错页面,根据异常的类型以及所在的模块,导航到出错页面。
一般来说,出错页面是更友好的做法。
另外还有特殊的处理方式,展示页面的模板可以捕获异常,并根据情况将异常信息铺到相应的位置,这样就更友好了,不过复杂度较高。
怎么处理,就看需要了。
五、总结
1)、对于异常处理,应该从设计、需要、维护等多个角度综合考虑,有一个通用准则:千万别捕获了异常什么事情都不干,这样一旦出现异常了,你没法依据异常信息来排错。
2)、对于J2EE多层架构系统来说,尽可能避免(因抛出异常带来的)接口污染。
以上论述仅代表个人观点,欢迎交流。
本文出自 “熔 岩” 博客,请务必保留此出处http://lavasoft.blog.51cto.com/62575/244138
异常的处理是每个Java程序员时常面对的问题,但是很多人没有原则,遇到异常也不知道如何去处理,于是遇到检查异常就胡乱try...catch...一把,然后e.printStackTrace()一下了事,这种做法通常除了调试排错有点作用外,没任何价值。对于运行时异常,则干脆置之不理。
原因是很多开发者缺乏对异常的认识和分析,首先应该明白Java异常体系结构,一种分层继承的关系,你必须对层次结构熟烂于心:
Throwable(必须检查)
Error(非必须检查)
Exception(必须检查)
RuntimeException(非必须检查)
一般把Exception异常及其直接子类(除了RuntimeException之外)的异常称之为检查异常。把RuntimeException以及其子类的异常称之为非检查异常,也叫运行时异常。
对于Throwable和Error,则用的很少,一般会用在一些基础框架中,这里不做讨论。
下面针对J2EE的分层架构:DAO层、业务层、控制层、展示层的异常处理做个分析,并给出一般处理准则。
一、DAO层异常处理
如果你用了Spring的DAO模板来实现,则DAO层没有检查异常抛出,代码非常的优雅。但是,如果你的DAO采用了原始的JDBC来写,这时候,你不能不对异常做处理了,因为难以避免的SQLException会如影随形的跟着你。对已这种DAO级别的异常,异常了你又能如何呢?与其这样胡乱try...catch...,囫囵吞枣消灭了异常不如让异常以另外一种非检查的方式向外传递。这样做好处有二:
1)、DAO的接口不被异常所污染,假设你抛出了SQLException,以后要是换了Spring DAO模板,那DAO接口就不再抛出了SQLException,这样,你的接口抛出异常就是对接口的污染。
2)、DAO异常向外传播给更高层处理,以便异常的错误原因不丢失,便于排查错误或进行捕获处理。
这里还有一个设计上常常令人困扰的问题:很多人会问,那定义一个什么样的异常抛出呢,或者是直接抛出一个throw RuntimeException(e)? 对于这个问题,需要分场合,如果系统小,你可以直接抛出一个throw RuntimeException(e),但对于一个庞大的多模块系统来说,不要抛这种原生的非检查异常,而要抛出自定义的非检查异常,这样不但利于排错,而且有利于系统异常的处理,通常针对每一个模块,粗粒度的定义一个运行时DAO异常。比如:throw new ModelXxxDAORuntimeException(".....",e),对于msg信息,你可写也可不写,根据需要灵活抛出。
这里常见一个很愚昧的处理方式,为每个DAO定义一个异常,呵呵,这样累不累啊,有多大意义,在Service层中调用时候,如果要捕获,还要捕获出一堆异常。这样致命的问题是代码混乱,维护困难,阅读也困难,DAO的异常应该是粗粒度的。
二、业务层异常处理
习惯上把业务层称之为Service层或者服务层,Service层的代表的是业务逻辑,不要迷信分太多太多层有多大好处,除非需要,否则别盲目划分不必要的层,层越多,效率越差,根据需要够用就行了。
Service接口中的每个方法代表一个特定的业务,而这个业务一定是一个完整的业务,通常会看到一些傻X的做法,数据库事务配置在Service层,而Service的实现就是DAO的直接调用,然后在控制层(Action)中,调用了好多Service去完成一个业务,你气得已经无语了,低头找砖头去!!!
搞明白以上两个问题后再回过头看异常怎么处理,Service层通常依赖DAO,而Service层的通常也会因为调用别的非检查异常方法而必须面对异常处理的问题,这里和DAO层又有所不同,彼一时,此一时嘛!
一般来说一个小模块对应一个Service,当然也许有两个或多个,针对这个模块的Service定义一个非检查异常,以应付那些不可避免的异常检查,这个自定义异常可以简单的命名为XxxServiceRuntimeException,将捕获到的异常顺势转译为非检查异常后抛出。我喜欢这么做,因为前台是J2EE应用,前台是web页面,它们的Struts2等框架会自动捕获所有Service层的异常,并把异常交给开发者去自由处理。
但是还有一种情况,由于一些特殊的限制,如果某个异常一旦发生,必须做什么什么处理,而这种处理时硬性要求,或者调用某个Service方法,必须检查处理什么异常,也可以抛出非检查的自定义异常,往往出现这种情况的是政治原因。不推崇这种做法,但也不排斥。
总之,对于接口,尽可能不去用异常污染她!
三、控制层异常
控制层说的简单些就是常见的Action层,主要是控制页面请求的处理。控制层通常都依赖于Service层,现在比较流行的框架对控制层做得都相当的到位,比如Struts2、SpringMVC等等,他们的控制层框架会捕获业务层的所有异常,并在控制层中声明可能抛出Exception,因此控制层一般不处理什么异常。
如果是控制层中因为调用了一些非检查异常的方法,比如IO操作等,可以简单处理下异常,保证流的安全,这才是目的。
四、显示层异常处理
对于页面异常,处理的方式多种多样,一是不处理异常,一旦异常了,页面就报错。二是定义出错页面,根据异常的类型以及所在的模块,导航到出错页面。
一般来说,出错页面是更友好的做法。
另外还有特殊的处理方式,展示页面的模板可以捕获异常,并根据情况将异常信息铺到相应的位置,这样就更友好了,不过复杂度较高。
怎么处理,就看需要了。
五、总结
1)、对于异常处理,应该从设计、需要、维护等多个角度综合考虑,有一个通用准则:千万别捕获了异常什么事情都不干,这样一旦出现异常了,你没法依据异常信息来排错。
2)、对于J2EE多层架构系统来说,尽可能避免(因抛出异常带来的)接口污染。
以上论述仅代表个人观点,欢迎交流。
本文出自 “熔 岩” 博客,请务必保留此出处http://lavasoft.blog.51cto.com/62575/244138
发表评论
-
底层读写-NIO实战
2016-03-04 10:51 824最近参与实现底层高并发处理的项目,接收socket ... -
底层网络读写
2016-03-04 10:49 566Java NIO:NIO概述 http://w ... -
java方法返回多个值
2016-01-22 09:11 763http://www.iteye.com/topic/114 ... -
模拟form表单上传图片
2016-01-19 17:23 750转自:http://blog.csdn.net/5iasp ... -
java包装类的几点注意
2016-01-18 10:52 796java中8种基本类型变量对应的包装类: ... -
JAVA调用聚合天气api接口示例
2016-01-15 09:42 4028http://www.iteye.com/topic/114 ... -
java对象序列化过程
2016-01-05 10:22 734一、 http://bbs.csdn.net/topi ... -
Java6 枚举常见7种用法
2014-02-09 23:02 846http://blog.csdn.net/shimiso/a ... -
异常 之 finally的特殊处理
2013-10-07 22:26 906http://java.chinaitlab.com/expe ... -
Java图片剪裁功能实现
2013-07-28 23:17 1493http://shensy.iteye.com/blog/16 ... -
让frameset居中
2013-07-25 19:59 0JSPHTML 平常我个人开发页面时,一般用width ... -
session生命周期
2013-07-23 08:40 0http://blog.sina.com.cn/s/blog_ ... -
转发和重定向的区别
2013-07-23 08:30 0http://www.2cto.com/kf/201107/9 ... -
NIO 之 BIO和NIO机制和socket
2013-07-14 18:38 1406https://www.ibm.com/developerwo ... -
win7下安装配置tomcat,java运行环境
2013-06-30 19:39 0http://www.cnblogs.com/pannysp/ ... -
JSP之 操作Cookie
2013-06-12 18:09 0Cookie应该是一 ... -
Socket实战之二 多线程通信
2013-05-31 15:15 0http://blog.csdn.net/kongxx/art ... -
Socket实战之七 使用Socket通信传输文件
2013-05-31 15:10 882http://blog.csdn.net/kongxx/art ... -
Socket实战之六 使用NIO包实现Socket通信
2013-05-31 15:06 1149本文地址:http://blog.csdn.net/kongx ... -
Socket实战之五 使用加密协议传输对象
2013-05-31 15:01 1286http://blog.csdn.net/kongxx/art ...
相关推荐
Java异常体系结构是Java语言的重要组成部分,它负责处理程序执行过程中出现的错误情况。在Java中,异常由Throwable类及其子类构成。Throwable是所有异常的顶层父类,它有两个直接子类:Error和Exception。Error类...
JDK1.7以上的异常体系,需要后续的不断总结和完善,学习jdk必备!
本文将深入探讨“异常体系的关键类”,结合源码分析,帮助开发者理解如何有效地利用Java的异常处理工具。 异常(Exception)是程序运行时发生的问题,它中断了正常的执行流程。Java异常类都是继承自`java.lang....
java异常体系结构包括许多异常类,他们之间存在继承关系
这个主题,"Java异常处理体系",涉及到Java如何优雅地处理程序运行时的异常,确保程序的健壮性和稳定性。这篇博文链接(已提供但无法直接访问)可能详细解释了Java异常处理的基本概念、机制以及最佳实践。 Java异常...
### Java异常体系概述 #### 什么是异常? 异常是指程序执行过程中出现的问题或错误情况。这些问题是正常的程序流程之外发生的,并且通常是由外部因素引起的,如用户输入错误、文件不存在等。Java通过提供一套异常...
简述什么是异常、异常的继承体系
13.java异常的体系结构.zip13.java异常的体系结构.zip13.java异常的体系结构.zip13.java异常的体系结构.zip13.java异常的体系结构.zip13.java异常的体系结构.zip13.java异常的体系结构.zip13.java异常的体系结构.zip...
Java异常体系结构的核心是`java.lang.Throwable`类,它是所有异常和错误的顶级父类。`Throwable`有两个直接子类,即`Error`和`Exception`。`Error`通常代表系统级或环境级别的问题,比如`OutOfMemoryError`和`...
Java异常体系是Java编程语言中一个至关重要的组成部分,它提供了优雅的方式来处理程序运行时可能出现的错误情况,确保程序的健壮性和可用性。异常处理机制允许开发者将正常的业务逻辑代码与错误处理代码分离,提高...
里面讲述了 java 异常体系,简介,及流程,可以让你对异常更加理解
Java异常体系基于一个类层次结构,以`java.lang.Throwable`为根,它有两个主要子类:`Error`和`Exception`。`Error`通常表示系统级别的错误,如`OutOfMemoryError`或`ThreadDeath`,这些错误往往超出程序员的控制...
本文将从 Java 异常的基本概念和语法开始,讲述 Java 异常处理的基本知识,分析 Java 异常体系结构,对比 Spring 的异常处理框架,阐述异常处理的基本原则,并提出了自己处理一个大型应用系统异常的思想,并通过设计...
异常分类体系3. 异常的抛出方式:throw & throws & 默认4. 异常的处理方式:try-catch-finally 1. 异常概念 概念:程序在运行过程中出现的特殊情况 必要性:任何程序都可能存在大量的位置问题、错误;如果不对这些...
Java异常体系结构主要分为两大类:检查型异常(Checked Exceptions)和非检查型异常(Unchecked Exceptions)。 #### 检查型异常 这类异常是指编译器要求必须处理的异常。如果一个方法声明抛出此类异常,那么调用...
在这个主题“PowerPC_体系结构之中断异常_powerpc_源码”中,我们将深入探讨PowerPC处理器如何处理中断和异常,以及在VxWorks操作系统环境下如何理解和解决相关问题。 在PowerPC体系结构中,中断和异常是处理器响应...
ARM 体系结构所支持的异常和具体含义如下: 1、复位(优先级1) 当处理器的复位电平有效时,产生复位异常,程式跳转到复位异常处执行(异常向量:0x0000,0000); 2、未定义指令(优先级...
"JAVA异常体系结构详解" Java异常体系结构是Java语言中的一种异常处理机制,它将异常当作对象来处理,并定义一个基类java.lang.Throwable作为所有异常的超类。 Java异常体系结构可以分为两大类:Error和Exception。...
#### 一、Java异常体系概览 在Java语言中,异常处理机制是一种用于处理程序运行时错误的重要机制。Java中的异常处理基于`java.lang.Throwable`类,它有两个重要的子类:`Exception`和`Error`。 1. **`Throwable`**...
AS3中的异常处理机制建立在一套层次化的异常类体系之上,`Error`基类位于最顶端,下面有多个子类,每个子类代表一种特定类型的错误。这种层次结构使得异常分类更加清晰,便于处理特定类型的异常。 - `Error`:所有...