2. 程式人生 > >Laravel核心解讀--異常處理

Laravel核心解讀--異常處理

阿新 • • 發佈：2019-02-17
異常 泄露 ext 而不是 apt 判斷 extend fatal nvi

異常處理是編程中十分重要但也最容易被人忽視的語言特性，它為開發者提供了處理程序運行時錯誤的機制，對於程序設計來說正確的異常處理能夠防止泄露程序自身細節給用戶，給開發者提供完整的錯誤回溯堆棧，同時也能提高程序的健壯性。

這篇文章我們來簡單梳理一下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 請求路由時HTTP Method不正確
  • 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的應用也是一樣。

來源：https://segmentfault.com/a/1190000018105686

Laravel核心解讀--異常處理

相關推薦

Laravel核心解讀--異常處理

異常 泄露 ext 而不是 apt 判斷 extend fatal nvi 異常處理是編程中十分重要但也最容易被人忽視的語言特性，它為開發者提供了處理程序運行時錯誤的機制，對於程序設計來說正確的異常處理能夠防止泄露程序自身細節給用戶，給開發者提供完整的錯誤回溯堆棧，同時也能

Laravel核心解讀--HTTP核心

Http Kernel Http Kernel是Laravel中用來串聯框架的各個核心元件來網路請求的，簡單的說只要是通過public/index.php來啟動框架的都會用到Http Kernel，而另外的類似通過artisan命令、計劃任務、佇列啟動框架進行處理的都會用到Console Kernel， 今

Laravel核心解讀--HTTP內核

路由 pat 對象傳輸 出發點 tex xtend buffer resolv 模塊 Http Kernel Http Kernel是Laravel中用來串聯框架的各個核心組件來網絡請求的，簡單的說只要是通過public/index.php來啟動框架的都會用到Http Ke

Laravel核心解讀 -- 擴充套件使用者認證系統

擴充套件使用者認證系統 上一節我們介紹了Laravel Auth系統實現的一些細節知道了Laravel是如何應用看守器和使用者提供器來進行使用者認證的，但是針對我們自己開發的專案或多或少地我們都會需要在自帶的看守器和使用者提供器基礎之上做一些定製化來適應專案，本節我會列舉一個在做專案時遇到的具體案例，在這個

Laravel 5.5 異常處理 & 錯誤日誌

簡介 Laravel 預設已經為我們配置好了錯誤和異常處理，我們在 App\Exceptions\Handler 類中觸發異常並將響應返回給使用者。 此外，Laravel 還集成了 Monolog 日誌庫以便提供各種功能強大的日誌處理器，預設情況下，Laravel 已經為

Laravel核心解讀--Console內核

判斷 func interface 響應 inpu one 周期 介紹 min Console內核 上一篇文章我們介紹了Laravel的HTTP內核，詳細概述了網絡請求從進入應用到應用處理完請求返回HTTP響應整個生命周期中HTTP內核是如何調動Laravel各個核心組件來

Laravel核心解讀--Console核心

Console核心 上一篇文章我們介紹了Laravel的HTTP核心，詳細概述了網路請求從進入應用到應用處理完請求返回HTTP響應整個生命週期中HTTP核心是如何調動Laravel各個核心元件來完成任務的。除了處理HTTP請求一個健壯的應用經常還會需要執行計劃任務、非同步佇列這些。Lar

Laravel 中的異常處理

這篇文章裡，我們將研究 Laravel 框架中最重要也最少被討論的功能 —— 異常處理。 Laravel 自帶了一個異常處理類，它能夠讓你以簡單、優雅的方式 report 和 render 異常。 文章的前半部分，我們將研究異常處理類（exception handler）提供的預設配置，然後研究異常處理類

Java匹馬行天下之JavaSE核心技術——異常處理

Java匹馬行天下之JavaSE核心技術——異常處理 異常的簡介 在Java中，異常就是Java在編譯、執行或執行過程中出現的錯誤。 程式錯誤分為三種：編譯錯誤、執行時錯誤和邏輯錯誤 編譯錯誤是因為程式沒有遵循語法規則，編譯程式能夠自己發現並且提示我們錯誤的原因和位置，這個也是新手

Laravel 5.1 中的異常處理器和HTTP異常處理 abort()

錯誤日誌 exce ant upload 記錄 再次 .org splay don 原文 http://laravelacademy.org/post/1867.html 錯誤和異常是處理程序開發中不可回避的議題，在本地開發中我們往往希望能捕獲程序拋出的異常並將其顯示打印

Laravel之加密解密/日誌/異常處理及自定義錯誤

文件中 例如 tom 處理器 crypt return cat 情況 而不是 一.加密解密 1.加密Crypt::encrypt($request->secret) 2.解密try { 　　$decrypted = Crypt::decrypt($encryptedV

Laravel 5.4 邏輯異常處理

Laravel 5.4 邏輯異常處理 修改 app\Exceptions\Handler.php public function render($request, Exception $exception) { if ($exception instanceof

java 核心技術卷I學習記錄（七）-異常處理

java 異常處理 1. 處理錯誤 異常處理的任務就是將控制權從錯誤產生的地方轉移給能夠處理這種情況的錯誤處理器 需要關注的錯誤種類有： 使用者輸入錯誤 裝置錯誤 物理限制 程式碼錯誤 1.1 異常分類 在java中，異常物件都是派生於

Java核心技術36篇③——異常處理機制

[toc] Java語言在設計之初就提供了相對完善的異常處理機制，大大提高了程式的可靠性。 異常的分類 我們編寫的程式都會經過編譯、執行這兩個階段，在這兩個階段都會出現異常。Java將這兩個階段的異常分別稱為Checked異常和Runtime異常： checked異常：在編譯階段被強制

詳細解讀php的異常處理機制

異常機制 一.異常基本知識 1.定義:異常處理用於在指定的錯誤(異常)情況發生時改變指令碼的正常流程,這過程稱為異常. 2.基本用法:  try {  //可能出現的錯誤(異常)程式碼  }  catch(Exception $e) { //自己處理：捕捉異常並處理, /

laravel-異常處理

laravel 異常丟擲 在開發中錯誤處理是非常重要的，最重要是兩點：第一，宣告異常的錯誤程式碼和資訊。第二，不同場景下丟擲異常的有所不同，比如 api 中一般是前端 ajax 請求，那麼丟擲的異常應該是 json 形式，如果是開發模式下，頁面中丟擲普通異常，

windows核心程式設計－－SEH（結構異常處理）

SEH 的工作原理。          Windows 程式設計中最重要的理念就是訊息傳遞，事件驅動。當GUI應用程式觸發一個訊息時，系統將把該訊息放入訊息佇列，然後去查詢並呼叫窗體的訊息處理函式(CALLBACK)，傳遞的引數當然就是這個訊息。我們同樣可以把異常也當作是

漫談相容核心之二十四:Windows的結構化異常處理(一)

結構化異常處理(Structured Exception Handling)，簡稱SEH，是Windows作業系統的一個重要組成部分。 在ReactOS核心的原始碼中，特別是在實現系統呼叫的程式碼中，讀者已經看到很多類似於這樣的程式碼：    if(MaximumSize

Java核心程式設計十：異常處理與日誌

1 異常層次 需要考察的異常情況有：使用者輸入錯誤、裝置錯誤、物理限制、程式錯誤，傳統的返回錯誤碼的方法並不能處理所有的情況。 1.1 異常分類 在Java程式中，異常物件都派生於Throwable。如果Java的內建異常不滿足需求，則可以建立自定義異常。下圖是基本的異

《Windows核心程式設計》讀書筆記二十五章 未處理異常，向量化異常處理與C++異常

第二十五章  未處理異常，向量化異常處理與C++異常 本章內容 25.1 UnhandledExceptionFilter函式詳解 25.2 即時除錯 25.3 電子表格示例程式 25.4 向量化異常和繼續處理程式 25.5 C++異常與結構化異常的比較 25.6 異常與