PHP 批鬥大會之缺失的異常

發表於2019-06-19
PHP
作為一名深度 phper，我如果要黑我們們 php，就像說自己母校差一樣，大家不要見外。
個人部落格地址：https://mengkang.net/1368.html

故事的開始

這幾天觀察錯誤日誌發現有一個資料反序列化的notice錯誤，實際情況我是從快取中讀取資料然後反序列化，因為反序列化失敗，所以實際每次都是去資料庫取的值。背後效能影響還是挺大的。

缺失的異常

剛開始寫程式碼的時候一直不明白為什麼要用異常，感覺if else就能搞定了，為什麼還要多此一舉，現在反而覺得 php 的異常太少。

對比兩種序列化場景，一個是json，另一個是serialize。

json

在json encode/decode的時候，如果出現異常，可以通過json_last_error()來獲取。

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

這樣的設計只能說勉強夠用，不太符合物件導向的套路。

serialize/unserialize

在使用自帶的序列化和反序列化的時候，相比json的處理，則更加簡單粗暴，沒有函式能拿到最後的錯誤，只會通過自定義的error handler來接管，然後自己去做出一些相應的處理。

為什麼要捕獲異常

比如我的程式碼比較亂，有的 key 是 json 序列化，有的 key 是 serialize。我們可以將 key 分類。不能確保其他人配置的對應關係是對的，或者有的人忘記了，所以我需要用捕獲異常的方式來兜底，這樣我們的程式碼更加健壯一些。當unserialize失敗之後，我們可以嘗試去json_decode，而不是立即返回一個false，從而把請求傳遞到資料庫。

程式碼演示

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 雖好，但是也不能貪杯哦。

相關文章