Laravel核心分析之異常處理（程式碼）
- 不言轉載
- 2019-02-11 10:22:422922瀏覽
這篇文章帶給大家的內容是關於Laravel核心分析之異常處理（程式碼），有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。
異常處理是程式設計中十分重要但也最容易被忽視的語言特性，它為開發者提供了處理程序運行時錯誤的機制，對於程式設計來說正確的異常處理能夠防止洩露程式本身細節給用戶，提供開發者完整的錯誤回溯堆疊，同時也能提高程式的健全性。
這篇文章我們來簡單梳理一下Laravel中提供的異常處理能力，然後講一些在開發中使用異常處理的實踐，如何使用自訂異常、如何擴展Laravel的異常處理能力。
註冊異常Handler
這裡又要回到我們說過很多次的Kernel處理請求前的bootstrap階段，在bootstrap階段的Illuminate\Foundation\Bootstrap\ HandleExceptions 部分中Laravel設定了系統異常處理行為並註冊了全域的例外處理器:
class HandleExceptions
{
public function bootstrap(Application $app)
{
$this->app = $app;
error_reporting(-1);
set_error_handler([$this, 'handleError']);
set_exception_handler([$this, 'handleException']);
register_shutdown_function([$this, 'handleShutdown']);
if (! $app->environment('testing')) {
ini_set('display_errors', 'Off');
}
}
public function handleError($level, $message, $file = '', $line = 0, $context = [])
{
if (error_reporting() & $level) {
throw new ErrorException($message, 0, $level, $file, $line);
}
}
}
set_exception_handler([$this, 'handleException'])將HandleExceptions的handleException方法註冊為程式的全域處理器方法:
public function handleException($e)
{
if (! $e instanceof Exception) {
$e = new FatalThrowableError($e);
}
$this->getExceptionHandler()->report($e);
if ($this->app->runningInConsole()) {
$this->renderForConsole($e);
} else {
$this->renderHttpResponse($e);
}
}
protected function getExceptionHandler()
{
return $this->app->make(ExceptionHandler::class);
}
// 渲染CLI请求的异常响应
protected function renderForConsole(Exception $e)
{
$this->getExceptionHandler()->renderForConsole(new ConsoleOutput, $e);
}
// 渲染HTTP请求的异常响应
protected function renderHttpResponse(Exception $e)
{
$this->getExceptionHandler()->render($this->app['request'], $e)->send();
}
在處理器裡主要透過ExceptionHandler的report方法上報異常、這裡是記錄異常到storage/laravel.log檔案中，然後根據請求類型渲染異常的回應產生輸出給客戶端。這裡的ExceptionHandler就是\App\Exceptions\Handler類別的實例，它是在專案最開始註冊到服務容器中的：
// bootstrap/app.php /* |-------------------------------------------------------------------------- | Create The Application |-------------------------------------------------------------------------- */ $app = new Illuminate\Foundation\Application( realpath(__DIR__.'/../') ); /* |-------------------------------------------------------------------------- | Bind Important Interfaces |-------------------------------------------------------------------------- */ ...... $app->singleton( Illuminate\Contracts\Debug\ExceptionHandler::class, App\Exceptions\Handler::class );
這裡再順便說一下set_error_handler函數，它的作用是註冊錯誤處理器函數，因為在一些年代久遠的程式碼或類別庫中大多是採用PHP那件函數trigger_error函數來拋出錯誤的，異常處理器只能處理Exception不能處理Error，所以為了能夠相容於老類別庫通常都會使用set_error_handler註冊全域的錯誤處理器方法，在方法中捕獲到錯誤後將錯誤轉換成異常再重新拋出，這樣專案中所有的程式碼沒有被正確執行時都能拋出異常實例了。
/**
* Convert PHP errors to ErrorException instances.
*
* @param int $level
* @param string $message
* @param string $file
* @param int $line
* @param array $context
* @return void
*
* @throws \ErrorException
*/
public function handleError($level, $message, $file = '', $line = 0, $context = [])
{
if (error_reporting() & $level) {
throw new ErrorException($message, 0, $level, $file, $line);
}
}
常用的Laravel例外實例
Laravel中針對常見的程式例外情況拋出了對應的例外實例，這讓開發者能夠捕捉這些執行時期異常並根據自己的需求來做後續處理（例如：在catch中呼叫另外一個補救方法、記錄異常到日誌檔案、發送警報郵件、簡訊）
在這裡我列一些開發中常遇到異常，並說明他們是在什麼情況下被拋出的，平時編碼中一定要注意在程式裡捕捉這些異常做好異常處理才能讓程式更健壯。
Illuminate\Database\QueryException Laravel中執行SQL語句發生錯誤時會拋出此異常，它也是使用率最高的異常，用來捕獲SQL執行錯誤，比方執行Update語句時很多人喜歡判斷SQL執行後判斷被修改的行數來判斷UPDATE是否成功，但有的情景裡執行的UPDATE語句並沒有修改記錄值，這種情況就沒法通過被修改函數來判斷UPDATE是否成功了，另外在事務執行中如果捕獲到QueryException 可以在catch程式碼區塊中回滾事務。
Illuminate\Database\Eloquent\ModelNotFoundException 透過模型的findOrFail和firstOrFail方法取得單一記錄時如果沒有找到會拋出這個例外(find和first找不到資料時會傳回NULL)。
Illuminate\Validation\ValidationException 請求未通過Laravel的FormValidator驗證時會拋出此例外。
Illuminate\Auth\Access\AuthorizationException 使用者要求未透過Laravel的政策（Policy）驗證時拋出此例外
Symfony\Component\Routing\Exception\MethodNotAllowedException 正確
Illuminate\Http\Exceptions\HttpResponseException Laravel的處理HTTP請求不成功時拋出此異常
#擴展Laravel的異常處理器
#上面說了Laravel把\App\Exceptions\Handler 註冊成功了全域的異常處理器，程式碼中沒有被catch到的異常，最後都會被\App\Exceptions\Handler捕獲到，處理器先上報異常記錄到日誌文件裡然後渲染異常響應再發送回應給客戶端。但是自帶的異常處理器的方法並不好用，很多時候我們想把異常上報到郵件或者是錯誤日誌系統中，下面的例子是將異常上報到Sentry系統中，Sentry是一個錯誤收集服務非常好用：
public function report(Exception $exception)
{
if (app()->bound('sentry') && $this->shouldReport($exception)) {
app('sentry')->captureException($exception);
}
parent::report($exception);
}
還有預設的渲染方法在表單驗證時產生回應的JSON格式往往跟我們專案裡統一的JOSN格式不一樣這就需要我們自訂渲染方法的行為。
public function render($request, Exception $exception)
{
//如果客户端预期的是JSON响应, 在API请求未通过Validator验证抛出ValidationException后
//这里来定制返回给客户端的响应.
if ($exception instanceof ValidationException && $request->expectsJson()) {
return $this->error(422, $exception->errors());
}
if ($exception instanceof ModelNotFoundException && $request->expectsJson()) {
//捕获路由模型绑定在数据库中找不到模型后抛出的NotFoundHttpException
return $this->error(424, 'resource not found.');
}
if ($exception instanceof AuthorizationException) {
//捕获不符合权限时抛出的 AuthorizationException
return $this->error(403, "Permission does not exist.");
}
return parent::render($request, $exception);
}
自定义后，在请求未通过FormValidator验证时会抛出ValidationException， 之后异常处理器捕获到异常后会把错误提示格式化为项目统一的JSON响应格式并输出给客户端。这样在我们的控制器中就完全省略了判断表单验证是否通过如果不通过再输出错误响应给客户端的逻辑了，将这部分逻辑交给了统一的异常处理器来执行能让控制器方法瘦身不少。
使用自定义异常
这部分内容其实不是针对Laravel框架自定义异常，在任何项目中都可以应用我这里说的自定义异常。
我见过很多人在Repository或者Service类的方法中会根据不同错误返回不同的数组，里面包含着响应的错误码和错误信息，这么做当然是可以满足开发需求的，但是并不能记录发生异常时的应用的运行时上下文，发生错误时没办法记录到上下文信息就非常不利于开发者进行问题定位。
下面的是一个自定义的异常类
namespace App\Exceptions\;
use RuntimeException;
use Throwable;
class UserManageException extends RuntimeException
{
/**
* The primitive arguments that triggered this exception
*
* @var array
*/
public $primitives;
/**
* QueueManageException constructor.
* @param array $primitives
* @param string $message
* @param int $code
* @param Throwable|null $previous
*/
public function __construct(array $primitives, $message = "", $code = 0, Throwable $previous = null)
{
parent::__construct($message, $code, $previous);
$this->primitives = $primitives;
}
/**
* get the primitive arguments that triggered this exception
*/
public function getPrimitives()
{
return $this->primitives;
}
}
定义完异常类我们就能在代码逻辑中抛出异常实例了
class UserRepository
{
public function updateUserFavorites(User $user, $favoriteData)
{
......
if (!$executionOne) {
throw new UserManageException(func_get_args(), 'Update user favorites error', '501');
}
......
if (!$executionTwo) {
throw new UserManageException(func_get_args(), 'Another Error', '502');
}
return true;
}
}
class UserController extends ...
{
public function updateFavorites(User $user, Request $request)
{
.......
$favoriteData = $request->input('favorites');
try {
$this->userRepo->updateUserFavorites($user, $favoritesData);
} catch (UserManageException $ex) {
.......
}
}
}
除了上面Repository列出的情况更多的时候我们是在捕获到上面列举的通用异常后在catch代码块中抛出与业务相关的更细化的异常实例方便开发者定位问题，我们将上面的updateUserFavorites 按照这种策略修改一下
public function updateUserFavorites(User $user, $favoriteData)
{
try {
// database execution
// database execution
} catch (QueryException $queryException) {
throw new UserManageException(func_get_args(), 'Error Message', '501' , $queryException);
}
return true;
}
在上面定义UserMangeException类的时候第四个参数$previous是一个实现了Throwable接口类实例，在这种情景下我们因为捕获到了QueryException的异常实例而抛出了UserManagerException的实例，然后通过这个参数将QueryException实例传递给PHP异常的堆栈，这提供给我们回溯整个异常的能力来获取更多上下文信息，而不是仅仅只是当前抛出的异常实例的上下文信息， 在错误收集系统可以使用类似下面的代码来获取所有异常的信息。
while($e instanceof \Exception) {
echo $e->getMessage();
$e = $e->getPrevious();
}
异常处理是PHP非常重要但又容易让开发者忽略的功能，这篇文章简单解释了Laravel内部异常处理的机制以及扩展Laravel异常处理的方式方法。更多的篇幅着重分享了一些异常处理的编程实践，这些正是我希望每个读者都能看明白并实践下去的一些编程习惯，包括之前分享的Interface的应用也是一样。
以上是Laravel核心分析之異常處理（程式碼）的詳細內容。更多資訊請關注PHP中文網其他相關文章！