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

看上面回答都是一致使用错误码来控制业务流程,我来说说我自己的想法

什么是异常?

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来解决。