令人讨厌的异常
提起异常，大家都很反感，当信心满满的写完一段代码，刷新页面发现上面写着大大的 Exception 是最心烦的时候了。模块给领导演示的时候，如果报了异常，也是最让人崩溃的时候了。
在一般的大型网站中，如果拥有异常处理的机制，那么将会帮助我们节省很多不需要的工作，具体如下：
什么是异常
异常是运行中超出了你程序预期的一个东西。
场景
例如京东有个 轻松购 的功能，当点击的时候会将该商品自动添加到购物车并生成订单，然后进行支付，这是一个网络请求，但是在后端实际执行了一系列的事情（以下操作是简单举例子便于说明问题，和真实步骤有差异）
- 验证用户是否登录
- 验证用户状态（如果被拉入系统黑名单就不能登录）
- 查看订单中物品是否实时有货
- 锁定货物（库存减少，支付中的货物数量 + 1）
- 生成订单
问题
步骤很多，如果任何一个环节出现问题，就要做响应的处理
- 用户没有登录就要保存购买信息，并跳转到登录页面
- 用户状态有问题则直接提示禁止继续购买
- 如果没有货物则跳转商品页面
- 同时购买人太多，自己购买时无货
处理思路
- 写到一个
controller里面，顺序执行，哪一步出错直接return? 这个controller该有多长，代码完全不可读，这是典型面向过程了。 - 封装几个业务方法返回
truefalse判断？比第一个好，但是就像编辑器多了折叠功能，其实还是面向过程的思路。
其实我们可以定义一个 购买流程的类 和一些异常了。下面是每个步骤的分析
- 需要在中间件验证用户是否登录，直接跳转。
- 可以写个中间件，命名为
BlacklistMiddleware专门处理黑名单，也是直接跳转到禁止界面。 - 此时其实已经到我们的业务处理类里面了，如果无货，你还会写跳转到无货页面吗？显然这里不合适了，因为你不知道什么时候需求变更（可以继续购买，只不过等待到货而已），如果真的跟需求变更来回改核心代码，累死也写不完程序了。建一个
NoGoodsException异常，当你业务处理类发现没有货，直接抛出该异常。然后在控制器中try catch捕获该异常进行后续处理，或者使用App\Exceptions\Handler进行统一处理。 - 如果你定义了上面的异常，那么你就尽情的抛出异常吧，已经有异常程序帮你处理后面的事情。
这样的好处就是，你的逻辑完全分离，不要再在业务逻辑代码里面考虑如何返回什么页面，要跳转到哪里，只考虑抛出合适的异常即可，简单的可以直接在 App\Exceptions\Handler 定义通用的捕获异常处理方式，这样的表现就非常统一了。如果需求高了，可以 try catch 后再根据情况再抛更详细的异常。
记录异常
对于某些异常，我们可能需要记录下来，以便方便发现问题，在 App\Exceptions\Handler 我们可以不去记录一些异常
最后针对不同的异常错误，可以做到相关信息记录，而我们只需要根据对应的分类找到对应的类库就可以
如果有实现疑问或者需要代码笔记，可以加入qq群交流与获取源码笔记：647617935