浅谈web开发中的异常

其实细想一下，检查业务异常码的过程不也是一个条件判断的过程吗？所以还是觉得用exception解决业务异常有些欠妥。当然这也和具体业务有关，我只是给些意见进行参考，防止走弯路。

关于这点，没有绝对的定义

我认为要从两个方面来考虑:
    一个是  失败率
    第二个是 接口的复杂程度


对于一个有非空约束的输入是不是空 这种情况，我建议最好用if来控制,这样效率较高，而且判定逻辑简单
而对于一个有唯一约束的输入我认为最好还是用exception!

公司的框架里这个早就给你规定好了~

我就觉得抛出异常的效率太底了，偶喜欢用方法返回特定的描述码，多写几行代码而已

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

    不知道我的理解正确不？

    还有楼上有人关于“取决于发生的频繁程度”的说法，我不太明白。

LZ,你说的异常太局限了吧.

取决于发生的频繁程度    指的是高并发吧..

楼主的建议大概明白 但是你举的例子不对

首先异常是不可见的,他并非符合不符合,比如你说的(
何为业务异常呢，先举个例子说明一下，例如在修改一个用户信息时，传递用户的年龄(age)不
应该大于其父母亲的年龄，因此在service层中必然会做一个和父母亲年龄作比较的业务判断，
一旦判断失败，在通常的处理中是返回一个标识，而我认为在业务中我们应该只关心正确流程，
也就是说整个程序没有执行失败的返回路径，作为替代，我们定义一种异常，向上层抛出，以标
识的失败，这种异常就是我们称为的业务异常)抱歉我不会引用

上面发生的不是异常,因为它可以在任何一个地方进行验证然后返回给用户验证信息.这是业务上的问题.不算异常

那么异常是什么呢???我觉得异常是服务端爆炸.或者是文件丢失.维修中 这算异常 因为无法避免或可见..

其次.异常只能在业务层(或者是低层)抛出然后由控制层捕捉返回给用户 低层不能捕捉异常 除非是一些需要 比如
finally 这段程序出现异常我仍然要执行下去

代码不是如何想着去捕捉异常,而是如何避免异常.异常这种东西还是少了为妙..

基本与lz的想法一致，对于违反业务规则的地方，应该抛出业务异常，但对于约束条件，还是倾向于用if判断

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

没看出这位的意义所在，异常的使用是并非是程序设计的问题。另外，log是做什么用的呀？看看log难道看不出来吗？呵呵
有些项目会要求异常记录在项目db的异常表中，那个地方可以实现你想要的功能。