try catch 什么时候用

Question

如果在控制器中 不管3721 先写个try catch

class Controller {

  try{
     $res = UserLogic::add($data);
     $res = userLogic::bb();
  } catch(\Exception $e){
    return $e;
  }

}

class UserLogic {

public static add($data){
    if(!isset($data['para'])) throw new \Exception('xxxx');
    
    Db::StartTrans();
    try{
        Db::commit();
    } catch(\Exception $e) {
        Db::rollBack();'
        throw $e;   这里是继续丢出去  个人感觉不是很优雅
    }
}

}

我比较困惑的地方是就是 是不是只要程序有不符合自己的地方就丢错误出去 在控制器统一处理 返回数据出去？如果处理这些异常信息会比较好呢？

Answer 1

阿里巴巴 Java 开发手册里有段话：（仅供参考）

【强制】异常不要用来做流程控制，条件控制。
说明：异常设计的初衷是解决程序运行中的各种意外情况，且异常的处理效率比条件判断方式要低很多。

用异常做流程控制，是件很爽的事情，因为它看清来更清晰、简单。但是它也有坏处，异常的创建意味着栈信息的收集等一系列有关的操作，这对于正常的业务来说除了拖累性能没有其他作用。

那到底该不该用异常处理业务逻辑呢？个人觉得，这是可取的。正如刚才说的，异常的优势就是清晰、简单，让我们的程序更好看，更容易明白。至于性能之类的，我想应该交给框架、语言去优化。

另外，自己不处理的异常，丢出去很优雅，也很符合原则。为什么你会觉得不好呢……

Answer 2

你这是把try catch用来做流程控制
讲道理是不合适的，可真实的代码确实有很多这么做的

Answer 3

1. 大部分异常不捕获，而是交有全局异常统一处理，这些代码写起来更简洁
2. 局部捕获异常代码，既然捕获了就需要做处理，像你代码里捕获了，又原封不动的抛出是没意义的。

Answer 4

错误和异常要分开的
错误就是错误，错误就要明确返回一个错误，告诉使用的地方，这里有问题，要按照错误的处理办法去处理。
异常也不是全部的异常都要捕获，而是，有不得不处理的异常才会去捕获处理，捕获了就要有处理，比如执行回滚，记录日志等，具体要结合业务看怎么处理是最合适的。