J2EE系统异常的处理准则

　2009-12-19 00:00:00　来源：WEB开发网　闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥堢亱闂佸湱铏庨崰鏍不椤栫偞鐓ラ柣鏇炲€圭€氾拷

闂傚倸鍊搁崐椋庣矆娓氣偓楠炲鏁撻悩鎻掔€梺姹囧灩閻忔艾鐣烽弻銉︾厵闁规鍠栭。濂告煕鎼达紕校闁靛洤瀚伴獮鎺楀箣濠靛啫浜鹃柣銏⑶圭壕濠氭煙閻愵剚鐏辨俊鎻掔墛缁绘盯宕卞Δ鍐冣剝绻涘畝濠佺敖缂佽鲸鎹囧畷鎺戭潩閹典焦鐎搁梻浣烘嚀閸ゆ牠骞忛敓锟�

婵犵數濮烽弫鍛婃叏椤撱垹绠柛鎰靛枛瀹告繃銇勯幘瀵哥畼闁硅娲熷缁樼瑹閳ь剙岣胯鐓ら柕鍫濇偪濞差亜惟闁宠桨鑳堕崝锕€顪冮妶鍡楃瑐闁煎啿鐖奸崺濠囧即閵忥紕鍘梺鎼炲劗閺呮稒绂掕缁辨帗娼忛埡浣锋闂佽桨鐒﹂幑鍥极閹剧粯鏅搁柨鐕傛嫹闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥堢亱闂佸湱铏庨崰鏍不椤栫偞鐓ラ柣鏇炲€圭€氾拷　　闂傚倸鍊搁崐鐑芥嚄閼哥數浠氱紓鍌欒兌缁垶銆冮崨鏉戠厺鐎广儱顦崡鎶芥煏韫囨洖校闁诲寒鍓熷铏圭磼濡搫顫嶅銈嗗姉閸樠囧煡婢跺á鐔兼煥鐎ｎ兘鍋撴繝姘拺鐟滅増甯掓禍浼存煕閹惧鈽夐柍缁樻煥椤繈鎳滅喊妯诲闂備礁鎲＄粙鎴︺偑閺夋垟鏋旈柡鍐ｅ亾缂佺粯绋撴禒锕傚磼濮橆剦鐎抽梻浣哥－缁垶骞戦崶顒傚祦閻庯綆浜栭弨浠嬫煙闁箑澧い鏂垮€规穱濠囨倷椤忓嫧鍋撻弽褜娼栧┑鐘宠壘閸屻劎鎲歌箛娑樼疅闁圭虎鍠楅弲鎼佹煥閻曞倹瀚�

核心提示： 1）、DAO的接口不被异常所污染，假设你抛出了SQLException，J2EE系统异常的处理准则(2)，以后要是换了Spring DAO模板，那DAO接口就不再抛出了SQLException，然后在控制层（Action）中，调用了好多Service去完成一个业务，这样，你的接口抛出异常就是对接

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去完成一个业务，你气得已经无语了，低头找砖头去！！！