解读 thinkphp5 源码（二）：异常处理和请求生命周期

php thinkphp5

上节 解读 thinkphp5 源码（一）：自动加载 看完了自动加载部分，根据代码执行顺序，base.php的59-64行

// 注册错误和异常处理机制
\think\Error::register();

// 加载惯例配置文件
\think\Config::set(include THINK_PATH . 'convention' . EXT);

下面的加载配置文件不用说，现在重点看一下异常处理。

打开 library/think/Error.php ，register函数。

public static function register(){
        error_reporting(E_ALL);
        set_error_handler([__CLASS__, 'appError']);
        set_exception_handler([__CLASS__, 'appException']);
        register_shutdown_function([__CLASS__, 'appShutdown']);
    }

通过 error_reporting() 来这是php的报错级别。E_ALL为显示所有报错信息，所以在运行时NOTICE级别的警告也会显示，如果不想显示NOTICE信息，可以在项目common文件中重新设置一下报错级别： error_reporting(E_ALL ^ E_NOTICE);

set_error_handler指定appError来处理系统异常

set_exception_handler来指定appException来处理用户抛出的异常

register_shutdown_function来指定appShutdown处理超时异常

然后使用getExceptionHandler方法来获取异常处理对象的实例。

public static function getExceptionHandler()
    {
        static $handle;
        if (!$handle) {
            // 异常处理handle
            $class = Config::get('exception_handle');
            if ($class && class_exists($class) && is_subclass_of($class, "\\think\\exception\\Handle")) {
                $handle = new $class;
            } else {
                $handle = new Handle;
            }
        }
        return $handle;
    }

里面有一句 $class = Config::get(‘exception_handle’); 也就是说我们可以通过修改配置参数来指定新的异常处理对象。

library/think/exception/ 下是几个异常处理类，主要就是在开启debug的情况下输出异常等级，异常信息，异常代码等等。然后也对CLI模式下做了异常输出的处理。
请求生命周期

应用初始化

base.php看完之后，基本上框架的初始化工作也做完了。然后回到，start.php中。

// 执行应用
App::run()->send();

这里是一个连贯操作，我们需要先看一下App::run()返回的是什么对象

library/think/App.php，run方法

run方法可以接收一个Request对象，如果不存在，则获取该对象。

is_null($request) && $request = Request::instance();

然后通过 $config = self::initCommon(); 来初始化应用

看initCommon()中的代码可以发现主要做了以下几件事情。

首先通过init()方法来初始化应用，主要就是加载该模块或者应用运行所需的文件，配置、common文件、语言包

然后判断如果配置中关闭debug的话则通过 ini_set(‘display_errors’, ‘Off’); 来关闭异常信息的显示。

ini_set(‘display_errors’, ‘Off’)和error_reporting(0)的区别主要在于，用前者设置后页面不显示异常信息，但是可以通过日志来收集异常信息，主要用在生产环境。而error_reporting(0);则屏蔽了所有异常信息，这种做法肯定是不太科学的。

然后判断如果不是cli模式下则重新申请一个缓冲区。使用缓冲区的作用主要是两方面，一是可以在输出一些内容之后在设置header（例如cookie等），使得程序设计的逻辑性变得简单；二是可以对缓冲区里面的输出内容撤销、删除、压缩、保存到文件等操作。

这里通过ob_get_level来判断缓冲区是否为空，来处理缓冲区的历史内容。

然后注册命名空间、加载额外文件、设置时区、注册app_init的hook。

回到run方法

if (defined('BIND_MODULE')) {
            // 模块/控制器绑定
            BIND_MODULE && Route::bind(BIND_MODULE);
        } elseif ($config['auto_bind_module']) {
            // 入口自动绑定
            $name = pathinfo($request->baseFile(), PATHINFO_FILENAME);
            if ($name && 'index' != $name && is_dir(APP_PATH . $name)) {
                Route::bind($name);
            }
        }

BIND_MODULE主要是来处理默认模块的，tp5的路由规则是 /m/c/a ，如果应用只有一个模块，则可以用过设置BIND_MODULE常量来设置模块名称。

通过配置auto_bind_module参数也可以设定模块名称。

$request->filter($config[‘default_filter’]); 注入过滤方法

开启多语言支持。

路由检测

// 获取应用调度信息
            $dispatch = self::$dispatch;
            if (empty($dispatch)) {
                // 进行URL路由检测
                $dispatch = self::routeCheck($request, $config);
            }
            // 记录当前调度信息
            $request->dispatch($dispatch);
            // 记录路由和请求信息
            if (self::$debug) {
                Log::record('[ ROUTE ] ' . var_export($dispatch, true), 'info');
                Log::record('[ HEADER ] ' . var_export($request->header(), true), 'info');
                Log::record('[ PARAM ] ' . var_export($request->param(), true), 'info');
            }

主要通过 self::routeCheck($request, $config); 来对路由进行分类，然后进行相应的操作（等后面进详细阅读）。主要有以下几种类别

路由到模块/控制器/操作；
路由到外部重定向地址；
路由到控制器方法；
路由到闭包函数；
路由到类的方法；

路由分发

根据上面得到分类，进行相应的操作，得到返回的数据（等后面进详细阅读）。

请求响应

主要通过Response类来进行响应。

注册app_end的hook，并返回response对象。

所以前面App::run()事实上得到的是一个经过一系列操作之后的response对象然后执行response->send();

拿到缓冲区中的数据，并输出，至此，结束请求。

本文由 lscho 创作，采用知识共享署名4.0国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: 09 07, 2018