故事的開始
這幾天觀察錯(cuò)誤日志發(fā)現(xiàn)有一個(gè)數(shù)據(jù)反序列化的notice錯(cuò)誤,實(shí)際情況我是從緩存中讀取數(shù)據(jù)然后反序列化,因?yàn)榉葱蛄谢。詫?shí)際每次都是去數(shù)據(jù)庫(kù)取的值。背后性能影響還是挺大的。
缺失的異常
剛開始寫代碼的時(shí)候一直不明白為什么要用異常,感覺if else就能搞定了,為什么還要多此一舉,現(xiàn)在反而覺得 php 的異常太少。
對(duì)比兩種序列化場(chǎng)景,一個(gè)是json,另一個(gè)是serialize。
json
在json encode/decode的時(shí)候,如果出現(xiàn)異常,可以通過json_last_error()來獲取。
https://www.php.net/manual/en...
這樣的設(shè)計(jì)只能說勉強(qiáng)夠用,不太符合面向?qū)ο蟮奶茁贰?/p>
serialize/unserialize
在使用自帶的序列化和反序列化的時(shí)候,相比json的處理,則更加簡(jiǎn)單粗暴,沒有函數(shù)能拿到最后的錯(cuò)誤,只會(huì)通過自定義的error handler來接管,然后自己去做出一些相應(yīng)的處理。
為什么要捕獲異常
比如我的代碼比較亂,有的 key 是 json 序列化,有的 key 是 serialize。我們可以將 key 分類。不能確保其他人配置的對(duì)應(yīng)關(guān)系是對(duì)的,或者有的人忘記了,所以我需要用捕獲異常的方式來兜底,這樣我們的代碼更加健壯一些。當(dāng)unserialize失敗之后,我們可以嘗試去json_decode,而不是立即返回一個(gè)false,從而把請(qǐng)求傳遞到數(shù)據(jù)庫(kù)。
代碼演示
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()); // 無法捕獲
}
輸出結(jié)果
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 代碼的異常設(shè)計(jì)還是任重而道遠(yuǎn)的,而這些已經(jīng)設(shè)定的“舊的規(guī)范”要推翻,需要“勇氣”,畢竟會(huì)影響所有的使用者。
好了,以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)腳本之家的支持。
您可能感興趣的文章:- 再談PHP錯(cuò)誤與異常處理
- PHP中的異常處理機(jī)制深入講解
- php中try catch捕獲異常實(shí)例詳解
- Thinkphp5框架異常處理操作實(shí)例分析
- 讓whoops幫我們告別ThinkPHP6的異常頁(yè)面
- Laravel 解決composer相關(guān)操作提示php相關(guān)異常的問題
- Thinkphp 在api開發(fā)中異常返回依然是html的解決方式
- PHP使用觀察者模式處理異常信息的方法詳解
- php異常處理捕獲錯(cuò)誤整理
- PHP中的異常及其處理機(jī)制