PHP 異常任重而道遠

做爲一名深度 phper,我若是要黑我們 php,就像說本身母校差同樣,你們不要見外。
我的博客地址: https://mengkang.net/1368.html

故事的開始

這幾天觀察錯誤日誌發現有一個數據反序列化的notice錯誤,實際狀況我是從緩存中讀取數據而後反序列化,由於反序列化失敗,因此實際每次都是去數據庫取的值。背後性能影響仍是挺大的。php

缺失的異常

剛開始寫代碼的時候一直不明白爲何要用異常,感受if else就能搞定了,爲何還要畫蛇添足,如今反而以爲 php 的異常太少。html

對比兩種序列化場景,一個是json,另外一個是serialize數據庫

json

json encode/decode的時候,若是出現異常,能夠經過json_last_error()來獲取。json

https://www.php.net/manual/en...

這樣的設計只能說勉強夠用,不太符合面向對象的套路。緩存

serialize/unserialize

在使用自帶的序列化和反序列化的時候,相比json的處理,則更加簡單粗暴,沒有函數能拿到最後的錯誤,只會經過自定義的error handler來接管,而後本身去作出一些相應的處理。安全

爲何要捕獲異常

好比個人代碼比較亂,有的 key 是 json 序列化,有的 key 是 serialize。咱們能夠將 key 分類。不能確保其餘人配置的對應關係是對的,或者有的人忘記了,因此我須要用捕獲異常的方式來兜底,這樣咱們的代碼更加健壯一些。unserialize失敗以後,咱們能夠嘗試去json_decode,而不是當即返回一個false,從而把請求傳遞到數據庫。bash

代碼演示

error_reporting(E_ALL);

$a = ["a" => 1];

class UnSerializeException extends ErrorException
{

}

set_error_handler(function ($severity, $message, $file, $line) {
    $info = explode(":", $message);

    if ($severity == E_NOTICE) {
        if ($info[0] == "unserialize()") {
            throw new UnSerializeException($message);
        }
        return true;
    } else {

        throw new ErrorException($message, 0, $severity, $file, $line);;
    }
});


try {
    $b = unserialize(json_encode($a));
} catch (ErrorException $exception) {
    var_dump(get_class($exception), $exception->getMessage(), $exception->getTraceAsString()); // 捕獲到了
} finally {
    restore_error_handler();
}

try {
    $b = unserialize(json_encode($a));
} catch (ErrorException $exception) {
    var_dump(get_class($exception), $exception->getMessage(), $exception->getTraceAsString()); // 沒法捕獲
}

輸出結果函數

string(20) "UnSerializeException"
string(43) "unserialize(): Error at offset 0 of 7 bytes"
string(181) "#0 [internal function]: {closure}(8, 'unserialize(): ...', '/Users/mengkang...', 34, Array)
#1 /Users/mengkang/PhpstormProjects/xxx/test.php(34): unserialize('{"a":1}')
#2 {main}"

Notice: unserialize(): Error at offset 0 of 7 bytes in /Users/mengkang/PhpstormProjects/xxx/test.php on line 42

後記

因此 php 代碼的異常設計仍是任重而道遠的,而這些已經設定的「舊的規範」要推翻,須要「勇氣」,畢竟會影響全部的使用者。性能

不少羣裏總是有語言之爭的聊天,我通常都看看罷了,也不參與。相似的例子,不勝枚舉,後面我會持續輸出一些 php 自黑的博客,但願 php 代碼更加健壯、安全。也但願你們不要只看到 php 幹活快,快的背後隱藏着無數的潛在風險,php 雖好,可是也不能貪杯哦。spa

也歡迎你們關注個人公衆號,不發騷擾,只發乾貨原創文章
圖片描述

相關文章
相關標籤/搜索