大体的业务流程我们是用try{}catch{}来控制,还是用if()来控制?

Question

1.比如说用户查看某些内容,我们要判断他是否有权限查看,这个时候我们应该是定义一个异常来处理,还是直接if()来处理?
2.catch{}有规范说抛给哪个层统一处理吗?还是根据实际情况各各层处理?
3.网上说try{}catch{}会对性能有影响,影响究竟多大?

这个问题本质应该是想问这两种控制流程到底有什么区别,就像Vicky和iMouseWu解释的那样,比如说try{}catch{}会交给JVM,这样做是提高了程序的健壮性,还是提高了程序的XX,请各位答主先抛弃try{}catch{}只能用来处理异常的想法再回答该题.

如果各位还有更好的回答,我会继续关注,采纳各位的答案,共同学习.

Answer 1

看上面回答都是一致使用错误码来控制业务流程,我来说说我自己的想法什么是异常?An exception (or exceptional event) is a problem that arises during the execution of a program. When an Exception occurs the normal flow of the program is disrupted and the program/Application terminates abnormally, which is not recommended, therefore these exceptions are to be handled按照这个解释,我们是不是也可以把业务上的错误当做一个异常流程来处理？所以当业务上出现比如题主说的「没有权限访问」,可以抛出一个异常。当然也可以通过接口返回错误码的方式完成。换个角度来看这个问题,来看下Java API中的一段代码 public String getCanonicalPath() throws IOException {    if (isInvalid()) {        throw new IOException("Invalid file path");    }    return fs.canonicalize(fs.resolve(this)); }那我们能不能把这个接口改成用错误码的方式来传递错误信息呢,当然也是可以的。至于Java API为什么在这里选择了用异常而不是用错误码,我想你也不希望你在你的代码的中需要对很多方法进行错误码判断吧,而我们的业务接口相对少一点,所以如果用错误码不会显得十分臃肿。至少到现在为止可以得出一个结论结论:用异常或者用错误码来控制业务流程都是可取的,只要整个团队统一风格就OK了。回到题主的问题上来,用异常来控制业务流程和用错误码来控制到底有什么优点和缺点。用错误码控制业务流程,需要对每个接口的返回都要做一个错误码的校验,判断的代码会遍布在你的业务代码里面。优点就是对调用方,不必对你的接口进行异常校验,因为你的接口只可能返回「正确」或者「错误」,在效率上面也会更加高一点。对某些人来说,用错误码来控制业务流程更能符合「异常」的语义。用异常来控制业务流程,可以把错误处理集中在一处,对客户端的代码编写更加友好,在业务代码里面不会有很多错误码的判断。缺点就是创建异常堆栈是需要时间和空间的,但是可以通过子类覆盖父类的fillInStackTrace来解决。参考异常(exception)和执行失败有什么区别LongjumpsConsideredInexpensiveExceptions or error codes

Answer 2

我见过有文章推荐使用try{}catch{}来进行业务逻辑处理，理由是Java的异常机制是由JVM控制的，而且将异常统一抛到最上层由一个统一的控制器进行管理，比如Spring，这样可以很好的对异常进行管理，等等理由。个人觉得异常就是异常，不可与正常的业务逻辑混到一起，异常是错误的场景，不然也不会叫做异常，既然是错误，那么我们要做的应该是尽量去避免，但是也不能卡的太死，比如DAO层就不去捕获异常，而由Service层进行捕获等。

Answer 3

try catch 语句一般都是用于捕获异常~ 或者runtime人为异常~ 不是那么适合用于业务逻辑~至于判断是否有权限看, 那要看你的业务需求, 比如一个业务有固定的权限level, 那么我也可以用switch 去做~ 相对代码量会少很多,

Answer 4

用 if 好。异常应该是预料中可能会发生的错误，而没有权限并非一个错误。catch 可以抛出给核心异常处理器(我比较喜欢的方式，异常统一处理，正常业务走正常逻辑，异常走核心异常处理器)，也可以由调用方捕获（如果需要），具体看业务实现。比如，访问数据库出错这种，就可以直接抛到核心，生成错误信息返回即可。如果是访问远程服务器，可能需要有连接出错重试机制，这个时候，就需要把连接异常抛给重连控制器。这个不清楚。知道的告诉一下。

Answer 5

用户的权限写在数据表里面，orm过来之后就是用户类的一个字段，当然用if来判断。如果你不希望代码块过深，可以先写权限验证失败的逻辑，这样就可以先渲染出失败的页面然后返回：if(!user.hasAuth())    return render(...);...try-catch也有好处，就是统一逻辑，如果if很多，而且失败时的逻辑相对单一（比如就只是显示个错误信息），用异常写着就比较舒服。但是如果每个失败处理不统一，就要定义很多个不同的异常类，不是特别省事。凡是能自己定义的东西（不是库里面抛出来的异常），可以用异常的地方也能返回一堆数据来判断。如果你把业务逻辑放进DAO，也可以充分利用返回值。所以我写DAO也好，EJB的SessionBean也好，都是直接返回一个Result类然后自己判断。另外别老想着性能，你用jsp的时候性能就已经被狗吃了。

Answer 6

可以用try..catch..（以下称为异常），我觉得此处应该用if..if用于同层中不同部分间的逻辑，如if真/假。异常用于嵌套层次间，如try{..throw..}catch()..。区分描述‘成功’‘失败’，‘正常’‘异常’。于是，if与过程结合更紧密——粒度强。而异常较笼统。可以先把失败情况下的信息通过异常抛出，如果需要，再在异常响应过程（catch）中通过if细分判断；也可在同一个过程中通过if细分正常情况及异常情况。两者响应能力亦不同，由于if可能仍在过程内，故，能享有过程中的其他数据的访问能力，而异常不可。看你怎么设计/定义两者的关系了——偏业务角度（if），或在实现上区分（异常）。我觉得可以问自己，两种情况是否处于同一个集合（如，真/假），若是，则不应使用不同的方式（返回值，或异常）去对待，若否，则可。另，我觉得，通过异常来简化问题处理只是省事，没有及时的（在异常发生处）进行处理，仍是一个笼统的处理方式2问 不知道。貌似，从调用栈的顶向底抛，直到被（用户或系统）处理。3问 不知道。（我更关心业务逻辑，如果实现方式性能差异不够重要的话）

Answer 7

if用于逻辑判断try catch是异常处理完全两回事吧你说的第一点肯定是用if判断的而且JAVA里有一些需要强制异常处理，不然就报错

Answer 8

if(有权限)能用的前提是假定别人也遵守. "遵守"在语法上是个可选的行为, 但是权限检查绝对不能是可选的. 所以总归要有异常, 那又何必多此一举提供另一种if的版本.异常的另一个好处是连可能的错误都没法无视, 不catch连编译都不行