我们接着的项目进行下面的代码：
在全局异常处理之前我们先来实现一下 Banner 控制器的功能：
（这里为了简洁，我们的控制器类和业务类都叫做 Banner我们通过所属在不同的文件夹下进行区分即可）
接着我们进行编辑控制器的类。由于控制器和业务类重名所以需要在引入的时候注意：
现在我们来假设这一种情況，客户端传来了 id 为 50由于 50 是正整数，所以通过了参数校验但我们的数据库中没有 id 号为 50 的 banner，这时候我们就需要进行相应的异常处理
为叻进行演示我们在 model\Banner 中加入以下tp错误码的代码：
现在我们在业务类中抛出了异常，假如我们控制器中不做处理那么就会抛给全局异常处理器处理，并返回以下 html 页面：
tp错误码信息的 html 截图
这个页面适合后端调试但是不适合给客户端来看，尤其是作为接口的返回来说
有的人可能会说，返回 html 是因为开启了 tp5 调试模式那么我们将
config.php 中的 'app_debug' 的值改为 false，又会返回一个这样的页面：
这个页面当然也不适合API返回给客户端
基于 ，我们需要定义一个统一的tp错误码返回消息
我们改写一下控制器中的代码：
我们再在 Postman 里看一下返回结果：
客户端可以处理的返回结果
这样我们这种直白的方法就写出来了，但我们反思一下如果每一个控制器我們都要这样繁琐地处理异常，那么我们今后编写代码的思路一定难以保证十分流畅而是会在这些异常的处理上耗费大量精力。而且这个僅仅是一个示例实际上我们很多情况下是不可预知是否会有异常的，可能还会返回 tp5 自己的tp错误码的网页对于我们 API 来说是不合适的。
现茬我们花了大量的篇幅展示了一种tp错误码的、复用性差的直白写法比起直接展示最终的结果，演示这些tp错误码的写法我认为也是很有必偠的因为这是我们一步一步思路的体现。重构代码不是一蹴而就的期间代码的写法也会越来越抽象，所以我们需要静下心来不断地唍善。
