to: wfeng007(风) 就是在处理业务时用的exception处理业务,感觉很方便的,基础框架,例如DAO层的CRUD操作我也封了些异常处理进去，例如: public PO findByPK(long id); 这里在最后做了如下处理: if(po==null) throw new PONotFoundException(); 这样的好处就是除BUG更快了，如果某个方法返回一个null，我们不会让它流逝到其他方法体里; to:jsjzzh(蚯蚓) 没听懂你说什么,或者是你没仔细看我写的？to:fdabobi(小爪尖尖) 增加系统资源的开销？给我个证明,我在看exception这部分的源码时，感觉它只是简单的把一些信息打印到栈里做同步处理,这和我们写一个方法再做些处理有什么不同呢？你这样的写法我上面说过了，和我以前一样,这样也不是不对,但这是面向过程的处理方法,如果是面向对象的处理，你觉的用户输入一个错误格式的用户名对于一个对象来说，是不是异常呢？
而且一个很直观的错误一般也不用异常处理，而对比较不好把握的情况时我们才使用它。
而且如果考虑到处理多线程，那么只要注意不要设置变量，而设计成方法间的参数传递，就不存在线程间的冲突啦
难道你不能写成
String username = X.getUsername();
String email = X.getEmail();
if(Checker.invalidUserName(username))
return Constant.INVALID_USER_NAME;
if(Checker.invalidEmail(email))
return Constant.INVALID_EAMIL;Checker只包含static的校验方法，接受参数返回boolean就可以啦，这样就不需要synchornized
就是在处理业务时用的exception处理业务,感觉很方便的,基础框架,例如DAO层的CRUD操作我也封了些异常处理进去，例如:
public PO findByPK(long id);
这里在最后做了如下处理:
if(po==null)
throw new PONotFoundException();
这样的好处就是除BUG更快了，如果某个方法返回一个null，我们不会让它流逝到其他方法体里;
to:jsjzzh(蚯蚓)
没听懂你说什么,或者是你没仔细看我写的？to:fdabobi(小爪尖尖)
增加系统资源的开销？给我个证明,我在看exception这部分的源码时，感觉它只是简单的把一些信息打印到栈里做同步处理,这和我们写一个方法再做些处理有什么不同呢？你这样的写法我上面说过了，和我以前一样,这样也不是不对,但这是面向过程的处理方法,如果是面向对象的处理，你觉的用户输入一个错误格式的用户名对于一个对象来说，是不是异常呢？
用户输入了错误格式，对于用户来说可能是异常，但是对于系统来说却不一定是。一个可以借鉴的例子是：hibernate以前所有的hibernateException都是checked exception,后来都换成了unchecked exception.
拿hibernateException做例子是不妥的,这就象你写个小方法，总不能这样吧
try{
//.......
}catch(NullPointerException e){
//do something.....
}
天知道你在try里有多少个可以抛出null的地方,hibernate也是如此,随着它体积的增大,天知道你会在一个try里做多少能抛出hibernateException的操作;
不知道楼主怎么得出这个结论的？
public int operation();public void process(){
int operate = operation();
if(operate==1)
//do something...
if(operate==2)
//do something...
if(operate==3)
//do something..
}
这样的写法，如果别人拿来使，怎么使？模块的可重用性明显不好，由于不是科班出身，我对OO的理解很弱，但我只觉的这样写，和那些机械仪表上的上下拨动的开关控制器一样，如果不给你一份详细的说明，你都不知道他们往上，往下拨动都是在做什么。
而使用异常则会好很多，起码知道这是一个异常状态，楼上有提到checked exception，所以刚又拿出effective java出来看了看，确实不太应该将流程控制放在catch block里；
看来还是太浮躁~~~读书不精呀~~~不过在应用里放一些NotFoundUserException也未尝不可吧 ^_^
而且用异常控制流程是不建议使用。当然，就事论事，看情况了。
public void operation()throws UserNotFoundException,InvalidPwdException;所以我当初才想这样应该比较好些吧~~？
还可以配置一个异常信息.properties
ding#####
请问这里可以灌水吗
至于楼主所说的“用户名格式错误”“密码格式错误”“邮箱格式不正确”之类的，可以采用javascript去实现！
还有struts框架中的验证你可以采用，如果还不能满足你所希望的功能，那你可以看看struts的源代码，然后对其进行修改！
尽量不要用异常去处理业务逻辑的东西！
个人认为，在f()->g()->h()->i()这样多层调用，又要根据一层一层返回值分支的程序，不如用异常来的清晰。还有比如你想抛出继承EJBException的异常来让容器回滚。这些情况下异常都是很有用的。
至于楼主的例子，比较简单，其实可以不用。
不过对于Pt_Coffee(Pt.Mr.咖啡)的问题~~~我不同层的exception都是继承这一层的父类异常,如果没有特殊需求，只要在catch块里捕捉这个父类异常就好了~~~
Anders认为不应该有应用程序业务的异常，应该只有Runtime的系统异常，否则改动接口需要异常匹配事件很烦的事情，但是James认为，你可以用异常来清晰你的Basic Flow控制，把alternative flow排除在弹栈抛异常的处理上，所以代码更清晰，而且严格意义的讲，改动接口需要异常匹配是强制要求调用者对可能的alternative flow的注意个人认为，James的观点更好。异常控制流程是完全可以的，是正确的，但是使用的场景要对。最常见的异常控制流程的例子就是EJB CMT,当你拿到一个业务异常或者系统异常，你需要回滚的时候，不管你的调用多复杂，多少层次，(比如EJB1 -> EJB2 -> EJB3 -> EJB4, 他们如果都是CMT, required)把你的异常封到一个EJBException里抛回去给容器就OK了，EJB的这种使用方式就是一种很经典的方式。
就用javascript搞定。
就用javascript搞定。
进步就是在思考和争论中得到的 ：）TO：den_dyj()
我从来不信任跑在本地的东西，JS这种东西从来都是防君子不防小人的；
比如常用的MVC，也就是在bean里有异常，servlet接一下给错误页，结构很简单，会有什么问题？
-------------------------
恩恩，减压才是JS的用途；
再说，如果你不用Exception，就得有返回值，还得有配套的程序处理它。这样做，不但代码增多结构容易混乱，而且你敢肯定处理的程序消耗的资源就比用exception消耗的小？
-----------------------------
我就是被绕烦了