我们接着重构 tp5 参数校验层的项目进行下面的代码：
在全局异常处理之前，我们先来实现一下 Banner 控制器的功能：
我们在 controller 的同级目录下新建一个 model 文件夹。在其下面新建一个 Banner 类。
（这里为了简洁，我们的控制器类和业务类都叫做 Banner，我们通过所属在不同的文件夹下进行区分即可）
<?php
namespace app\api\model;
class Banner{
public static function getBannerById($id){
//TODO: 根据 Banner ID 号，获取 Banner 信息
return 'banner info';
}
}
接着我们进行编辑控制器的类。由于控制器和业务类重名，所以需要在引入的时候注意：
<?php
namespace app\api\controller\v1;
use app\api\validate\IDMustBePositiveInt;
use app\api\model\Banner as BannerModel;
class Banner{
public function getBanner($id){
(new IDMustBePositiveInt())->goCheck();
$banner = BannerModel::getBannerByID($id);
return $banner;
}
}
现在我们来假设这一种情况，客户端传来了 id 为 50，由于 50 是正整数，所以通过了参数校验，但我们的数据库中没有 id 号为 50 的 banner，这时候我们就需要进行相应的异常处理。
为了进行演示我们在 model\Banner 中加入以下错误的代码：
try{
1/0;
}
catch(Exception $e){
throw $e;
}
现在我们在业务类中抛出了异常，假如我们控制器中不做处理，那么就会抛给全局异常处理器处理，并返回以下 html 页面：
错误信息的 html 截图
这个页面适合后端调试，但是不适合给客户端来看，尤其是作为接口的返回来说。
有的人可能会说，返回 html 是因为开启了 tp5 调试模式，那么我们将
config.php 中的 'app_debug' 的值改为 false，又会返回一个这样的页面：
这个页面当然也不适合API返回给客户端
那么我们在设计接口的时候该如何向客户端返回错误信息呢？
基于 RESTFul 规范，我们需要定义一个统一的错误返回消息。
我们改写一下控制器中的代码：
class Banner{
public function getBanner($id){
(new IDMustBePositiveInt())->goCheck();
try{
$banner = BannerModel::getBannerByID($id);
}
catch(Exception $e)
{
$err = [
'error_code' => 10001,
'msg' => $e->getMessage()
];
return json($err,400); // 注意不能直接返回数组，而应该用json包一下
}
return $banner;
}
}
我们再在 Postman 里看一下返回结果：
客户端可以处理的返回结果
400状态码
这样我们这种直白的方法就写出来了，但我们反思一下，如果每一个控制器我们都要这样繁琐地处理异常，那么我们今后编写代码的思路一定难以保证十分流畅，而是会在这些异常的处理上耗费大量精力。而且这个仅仅是一个示例，实际上我们很多情况下是不可预知是否会有异常的，可能还会返回 tp5 自己的错误的网页，对于我们 API 来说是不合适的。
现在我们花了大量的篇幅展示了一种错误的、复用性差的直白写法，比起直接展示最终的结果，演示这些错误的写法我认为也是很有必要的，因为这是我们一步一步思路的体现。重构代码不是一蹴而就的，期间代码的写法也会越来越抽象，所以我们需要静下心来，不断地完善。
