浅谈web开发中的异常

个人觉得用异常要慎重，处理异常耗费资源，且处理不好容易造成很多不必要的麻烦....

楼主的建议大概明白 但是你举的例子不对 首先异常是不可见的,他并非符合不符合,比如你说的( 何为业务异常呢，先举个例子说明一下，例如在修改一个用户信息时，传递用户的年龄(age)不 应该大于其父母亲的年龄，因此在service层中必然会做一个和父母亲年龄作比较的业务判断， 一旦判断失败，在通常的处理中是返回一个标识，而我认为在业务中我们应该只关心正确流程， 也就是说整个程序没有执行失败的返回路径，作为替代，我们定义一种异常，向上层抛出，以标 识的失败，这种异常就是我们称为的业务异常)抱歉我不会引用 上面发生的不是异常,因为它可以在任何一个地方进行验证然后返回给用户验证信息.这是业务上的问题.不算异常 那么异常是什么呢???我觉得异常是服务端爆炸.或者是文件丢失.维修中 这算异常 因为无法避免或可见.. 其次.异常只能在业务层(或者是低层)抛出然后由控制层捕捉返回给用户 低层不能捕捉异常 除非是一些需要 比如 finally 这段程序出现异常我仍然要执行下去 代码不是如何想着去捕捉异常,而是如何避免异常.异常这种东西还是少了为妙..

showtime520 写道
我就觉得抛出异常的效率太底了，偶喜欢用方法返回特定的描述码，多写几行代码而已    我觉得你这种做法不一定能解决楼主说的情况。     我没有用过楼主所说的那种“业务异常”（只是看到过），我的理解是，这种“业务异常”属于“正常返回之外的一种返回”，按你说的“方法返回特定的描述码”那样，所有调用了“会抛出‘业务异常’的方法”的，却没有处理这些情况（那些异常或错误码）的能力的方法，它们岂不是也得在自己的返回中（在return中）也加上描述码（以返回给上一层的调用者）？     使用“业务异常”后，与返回描述码相比，接口相当于更加“显式”（或更加强的约束）了——也就是说，实现者在调用那些方法时，会明确的知道它们会抛出那些异常，而如果他自己不能处理，他可以继续向上抛（直到可以处理的）。     不知道我的理解正确不？     还有楼上有人关于“取决于发生的频繁程度”的说法，我不太明白。

LZ,你说的异常太局限了吧. 取决于发生的频繁程度    指的是高并发吧..

呵呵，正解啊

何为业务异常呢，先举个例子说明一下，例如在修改一个用户信息时，传递用户的年龄(age)不应该大于其父母亲的年龄，

楼主的见解有独到之处,但是个人意见觉得没有必要在service层定义过多的业务异常.本身开发过程中一些异常流程可以用ifelse语句控制,定义过多的异常貌似没有很多必要,而且会增加复杂度.
个人意见,不对的地方请指正