异常是所有开发者在写代码过程中都会遇到并且要妥善处理的，不少开发者认为PHP无需做异常处理，框架本身已经帮我们做好了，异常处理是 Java ，C语言才要做的事情，其实这种说法是很片面的，虽然PHP的框架比如 laravel ,Yii等有非常好的异常处理，但是他们只是提供了一种工具，框架不会去理解业务，而在业务逻辑中，难免会遇到各种异常处理，我们要提升对异常的认知，做到在工作中灵活运用 ”
接下来在异常处理这篇文章中,我将从头梳理PHP开发中 exception 这个关键字的周边知识,争取梳理清楚如下的几个问题
1.什么是异常
2.异常从哪里来
3.异常应该到哪里去
4.异常之分门别类
5.异常和错误的区别和联系
6.异常之于业务场景
什么是异常
在我们开始所有解释之前,我么首先举个栗子. 假设你要按照给定id来查找humans表的用户邮箱,这个功能可以写成这样:
但是这绝对不是一个健壮的代码,一旦用户传递一个不存在的id(数据库不存在),或者传递是压根就不是int型的正整数,程序就会进入: PHP Notice 状态,导致整个程序进入非预期流程
这里的非预期流程可能是个PHP层的警告,也可能是个fatal error(假设方法的实现还有更加致命的逻辑假设),导致程序异常终止
所以这时候需要这个方法告诉调用方你的参数有误这种信息,这个时候通常我们的做法有两种.
1.
2.
而第二种做法就是我们讨论的Exception,好了,到这里我们只是讨论清楚了抛出异常的必要性,但是就如上面两个例子看到的,调用方调用完毕这个方法怎么按照你给的信号(throw 出来的exception)做出合理的处理呢?
异常从哪里来?
上面说清楚了异常的必要性以及可能性,那么异常从哪里来呢?
异常来自开发者对整体代码逻辑的非预期结果给出的提示. 所以简单来说,异常是PHP代码层抛出的. 一般常见的当我们调用第三方接口，如果不做异常处理，接口异常，或者超时，都会产生致命性错误。
异常应该到哪里去
上面已经定义了function getHumanEmailById,同时对参数的非法性做了异常的抛出,但是我们不知道异常到哪里去了,我们尝试调用它getHumanEmailById(1),这里假设id是1的human信息在数据库中已经被删除,看看PHP执行器返回结果:
Fatal error: Uncaught InvalidArgumentException: 参数非法 这里发现,我们抛出的异常居然变成了Fatal error,所以异常抛出后交给了PHP解释器,解释器没有找到 catch 这个异常的逻辑代码,所以直接fatal error,说明这一点
我们继续修改代码
执行结果正常输出: 参数非法 在Laravel中，内置了非常多的异常处理类，如果我们善于观察，可能会经常遇到 诸如router 404, 405Method Not Allowed 429 to many request ,model 404 这样的laravel 已经帮我们处理的异常处理，当然还是开头那句话，我们业务的异常，框架是不会帮我们处理的 到此,我们解释清楚了异常应该到哪里去的问题
异常之分门别类
也许你留意到上面的代码没有catch InvalidArgumentException,是因为Exception是InvalidArgumentException的父类,因为异常的类型很多,我们有一些需求确实需要根据不同的异常做不同的事情,例如下面的伪代码:
异常和错误的区别和联系
这个主题,我想只有PHP官方PHP5时代的开发才能解释清楚这一点,通俗的来说,错误可能是不可修复的,当然现在的PHP7版本已经将error和exception统一了,他们都集成自throwable这个interface.具体的关系如图
PHP7以下的话,我们可以尝试将error转为exception,具体实现代码:
异常之于业务场景
特定一类throwable统一输出json 最后,我们回归到上面最初的代码,如果human的id是非法的,就抛出了异常,假设这个id恰好是业务前端传递的,我们就需要告诉用户这个id是非法的,明确告诉他非法请求. 实现的逻辑代码大致为:
如果这中参数对应的msg想统一起来,且前端提交的参数非常多,都需要这样判断呢? 这里我们可以抽象出有一个类,继承自InvalidArgumentException的类ApiInvalidArgumentException,然后统一在上层捕获这个异常,然后统一输出json格式 这里的最佳实践可以在laravel中看到影子,大致思路如下:
1.继承IlluminateFoundationExceptionsHandler::render($request, Exception $e)
2.ApiInvalidArgumentException类定义toJson方法
3.拿到$e,特判ApiInvalidArgumentException,return出tojson
如此对业务代码无侵入,看起来干净且明了
将没有catch的异常介入第三方统计 线上在所难免的会有一些异常是未捕获的,这时PHP会将信息直接fatal error,并输出堆栈信息,所以我们可以将这些信息介入第三方,实时发消息给开发者,解决和发现线上问题. 推荐大家使用sentry作为PHP异常处理和发现的工具,很强大,目前我们团队线上就在大量使用.
因为我们的业务需要判断和处理太多不符合预期的结果了,有时候一个鲁棒性强的代码可能是核心业务代码的2-3倍,这个时候如果我们能够很好的利用exception,既能让代码健壮,又能让健壮性判断可读性高,例如我们可以二次封装if判断,转变为assert断言,然后在断言中抛出异常.现在很多第三方类库,都很好的定义了自己的异常,为的就是健壮和可读性,希望通过这篇文章,大家能够收获一些新的心得体会,也希望你能斧正文章的错误。
