tp5.1 API 自定义全局异常处理（上）

我们接着重构 tp5.1 参数校验层的项目进行下面的演示。
现在我们来假设这一种情况，客户端传来了 id 为 50，由于 50 是正整数，所以通过了参数校验，但我们的数据库中没有 id 号为 50 的user，这时候我们就需要进行相应的异常处理。注：在Restful API开发中，查询不到数据也可认为是异常
为了演示，我们手动在User控制器中手动抛出一个异常:

public function getUserById($id)
{
     
        (new IDMustBePositiveInt())->goCheck();
        throw new \think\Exception('手动异常', 10006);
 }

假如我们控制器中不做处理，那么就会抛给全局异常处理器处理，并返回以下 html 页面：

这个页面适合后端调试，但是不适合给客户端来看，尤其是作为接口的返回来说。
那么我们在设计接口的时候该如何向客户端返回错误信息呢？
基于 RESTFul 规范，我们需要定义一个统一的错误返回消息。
我们改写一下控制器中的代码：

  public function getUserByid($id){
     
    (new IDMustBePositiveInt())->goCheck();
    try{
     
      throw new \think\Exception('手动异常', 10006);
    } 
    catch(Exception $e)
    {
     
      $err = [
        'error_code' => 10001,
        'msg' => $e->getMessage()
      ];
      return json($err,400); // 注意不能直接返回数组，而应该用json包一下
    }
  }

返回的页面：

这样我们这种直白的方法就写出来了，但我们反思一下，如果每一个控制器我们都要这样繁琐地处理异常，那么我们今后编写代码的思路一定难以保证十分流畅，而是会在这些异常的处理上耗费大量精力。而且这个仅仅是一个示例，实际上我们很多情况下是不可预知是否会有异常的，可能还会返回 tp5 自己的错误的网页，对于我们 API 来说是不合适的。

现在我们花了大量的篇幅展示了一种错误的、复用性差的直白写法，比起直接展示最终的结果，演示这些错误的写法我认为也是很有必要的，因为这是我们一步一步思路的体现。重构代码不是一蹴而就的，期间代码的写法也会越来越抽象，所以我们需要静下心来，不断地完善。
tp5.1 API 自定义全局异常处理（中）