在 AppServiceProvider 中添加错误处理时,会报 Class api.exception does not exist 错误
class AppServiceProvider extends ServiceProvider
{
/**
* Bootstrap any application services.
*
* @return void
*/
public function boot()
{
//
}
/**
* Register any application services.
*
* @return void
*/
public function register()
{
//
API::error(function (ModelNotFoundException $exception) {
abort(404);
});
}
}
报错:
尝试过在config/api.php中添加exception配置,但是还是会报这个错误。
config/api.php中的exception配置:
'exception' => [
\Dingo\Api\Exception\Handler::class,
\Dingo\Api\Contract\Debug\ExceptionHandler::class
]
关于 LearnKu
register 方法是用来绑定服务到服务容器的, 要想使用某个类实例的话, 最好放在boot方法中。
报错是容器中不存在 api.exception,但是只要装了dingo,就应该被注册了,tinker 中试一下。拿项目源码试一下,对比看看哪的问题
@liyu001989 我在tinker中测试显示exception的配置是有的,但是在register中绑定错误处理的时候就是会报错
https://github.com/summerblue/larabbs/tree... 对比一下源码吧
对比源码之后发现,按照源码那种放到register里面去绑定的话就是会报错,放到boot里面绑定就是正常的,应该是生命周期的问题。目前是已经正常了,我再去捋一捋生命周期这块
@luke05 个人也觉得 boot 里面更合适,注册只负责注册这一件事。注册好后还需要类似初始化的操作就放到 boot 里面。 不知道这样理解行不行
@FreeMason 可以按你的理解... 需要使用服务容器中的服务时, 最好不要在register方法中使用,除非你很确定程序执行到该位置时你所引用的服务已经注册。在boot中所有的服务基本上都已经绑定好了, 可以直接使用
api.exception字符串去实例化一个\Dingo\Api\Exception\Handler对象,然后使用这个Handler对象的register方法,去注册一个异常注册handler。api.exception没有在appServiceProvider前注册成功的,也有一定道理。但是当你理解了注册serviceProvider的先后顺序后,就会明白api.exception早就已经在注册appServiceProvider前注册成功了。上述代码的含义是:
Illuminate关键字开头的标准分为两组。bootstrap/cache/services.php,这个缓存文件是按照provider的defer属性去分的。如果有缓存文件,那么在
\Illuminate\Foundation\ProviderRepository::load方法中,就会去取缓存文件数组中的eager数组,可以看到缓存文件里面eager数组内Provider的顺序跟我们上面分析的顺序是一致的。缓存文件内的截图:

api.exception是在哪里注册了? 上面已经标明了是在Dingo\Api\Provider\LaravelServiceProvider。进入LaravelServiceProvider,查看其注册方法:
再看父类的注册方法:
$this->registerExceptionHandler(),进去看看:@hustnzj 分析的相当精彩 建议兄弟 整理整理 单独发博客
@hustnzj 大神