JavaScript 錯誤處理和堆疊追蹤淺析
有時我們會忽略錯誤處理和堆疊追蹤的一些細節, 但是這些細節對於寫與測試或錯誤處理相關的庫來說是非常有用的. 例如這周, 對於 Chai 就有一個非常棒的PR, 該PR極大地改善了我們處理堆疊的方式, 當使用者的斷言失敗的時候, 我們會給予更多的提示資訊(幫助使用者進行定位).
合理地處理堆疊資訊能使你清除無用的資料, 而只專注於有用的資料. 同時, 當更好地理解 Errors
物件及其相關屬性之後, 能有助於你更充分地利用 Errors
.
(函式的)呼叫棧是怎麼工作的
在談論錯誤之前, 先要了解下(函式的)呼叫棧的原理:
當有一個函式被呼叫的時候, 它就被壓入到堆疊的頂部, 該函式執行完成之後, 又會從堆疊的頂部被移除.
堆疊的資料結構就是後進先出, 以 LIFO (last in, first out) 著稱.
例如:
function c() { console.log('c'); } function b() { console.log('b'); c(); } function a() { console.log('a'); b(); } a();
在上述的示例中, 當函式 a
執行時, 其會被新增到堆疊的頂部. 然後, 當函式 b
在函式 a
的內部被呼叫時, 函式 b
會被壓入到堆疊的頂部. 當函式 c
在函式 b
的內部被呼叫時也會被壓入到堆疊的頂部.
當函式 c
執行時, 堆疊中就包含了 a
, b
和 c
(按此順序).
當函式 c
執行完畢之後, 就會從堆疊的頂部被移除, 然後函式呼叫的控制流就回到函式 b
. 函式 b
執行完之後, 也會從堆疊的頂部被移除, 然後函式呼叫的控制流就回到函式 a
. 最後, 函式 a
執行完成之後也會從堆疊的頂部被移除.
為了更好地在demo中演示堆疊的行為, 可以使用 console.trace()
在控制檯輸出當前的堆疊資料. 同時, 你要以從上至下的順序閱讀輸出的堆疊資料.
function c() { console.log('c'); console.trace(); } function b() { console.log('b'); c(); } function a() { console.log('a'); b(); } a();
在 Node 的 REPL 模式中執行上述程式碼會得到如下輸出:
Trace at c (repl:3:9) at b (repl:3:1) at a (repl:3:1) at repl:1:1 // <-- For now feel free to ignore anything below this point, these are Node's internals at realRunInThisContextScript (vm.js:22:35) at sigintHandlersWrap (vm.js:98:12) at ContextifyScript.Script.runInThisContext (vm.js:24:12) at REPLServer.defaultEval (repl.js:313:29) at bound (domain.js:280:14) at REPLServer.runBound [as eval] (domain.js:293:12)
正如所看到的, 當從函式 c
中輸出時, 堆疊中包含了函式 a
, b
以及c
.
如果在函式 c
執行完成之後, 在函式 b
中輸出當前的堆疊資料, 就會看到函式 c
已經從堆疊的頂部被移除, 此時堆疊中僅包括函式 a
和 b
.
function c() { console.log('c'); } function b() { console.log('b'); c(); console.trace(); } function a() { console.log('a'); b(); }
正如所看到的, 函式 c
執行完成之後, 已經從堆疊的頂部被移除.
Trace at b (repl:4:9) at a (repl:3:1) at repl:1:1 // <-- For now feel free to ignore anything below this point, these are Node's internals at realRunInThisContextScript (vm.js:22:35) at sigintHandlersWrap (vm.js:98:12) at ContextifyScript.Script.runInThisContext (vm.js:24:12) at REPLServer.defaultEval (repl.js:313:29) at bound (domain.js:280:14) at REPLServer.runBound [as eval] (domain.js:293:12) at REPLServer.onLine (repl.js:513:10)
Error物件和錯誤處理
當程式執行出現錯誤時, 通常會丟擲一個 Error
物件. Error
物件可以作為使用者自定義錯誤物件繼承的原型.
Error.prototype
物件包含如下屬性:
constructor
–指向例項的建構函式message
–錯誤資訊name
–錯誤的名字(型別)
上述是 Error.prototype
的標準屬性, 此外, 不同的執行環境都有其特定的屬性. 在例如 Node, Firefox, Chrome, Edge, IE 10+, Opera 以及 Safari 6+ 這樣的環境中, Error
物件具備 stack
屬性, 該屬性包含了錯誤的堆疊軌跡. 一個錯誤例項的堆疊軌跡包含了自建構函式之後的所有堆疊結構.
如果想了解更多關於 Error
物件的特定屬性, 可以閱讀 MDN 上的這篇文章.
為了丟擲一個錯誤, 必須使用 throw
關鍵字. 為了 catch
一個丟擲的錯誤, 必須使用 try...catch
包含可能跑出錯誤的程式碼. Catch的引數是被跑出的錯誤例項.
如 Java 一樣, JavaScript 也允許在 try/catch
之後使用 finally
關鍵字. 在處理完錯誤之後, 可以在 finally
語句塊作一些清除工作.
在語法上, 你可以使用 try
語句塊而其後不必跟著 catch
語句塊, 但必須跟著 finally
語句塊. 這意味著有三種不同的 try
語句形式:
try...catch
try...finally
try...catch...finally
Try語句內還可以在嵌入 try
語句:
try { try { throw new Error('Nested error.'); // The error thrown here will be caught by its own `catch` clause } catch (nestedErr) { console.log('Nested catch'); // This runs } } catch (err) { console.log('This will not run.'); }
也可以在 catch
或 finally
中嵌入 try
語句:
try { throw new Error('First error'); } catch (err) { console.log('First catch running'); try { throw new Error('Second error'); } catch (nestedErr) { console.log('Second catch running.'); } }
try { console.log('The try block is running...'); } finally { try { throw new Error('Error inside finally.'); } catch (err) { console.log('Caught an error inside the finally block.'); } }
需要重點說明一下的是在丟擲錯誤時, 可以只丟擲一個簡單值而不是 Error
物件. 儘管這看起來看酷並且是允許的, 但這並不是一個推薦的做法, 尤其是對於一些需要處理他人程式碼的庫和框架的開發者, 因為沒有標準可以參考, 也無法得知會從使用者那裡得到什麼. 你不能信任使用者會丟擲 Error
物件, 因為他們可能不會這麼做, 而是簡單的丟擲一個字串或者數值. 這也意味著很難去處理堆疊資訊和其它元資訊.
例如:
function runWithoutThrowing(func) { try { func(); } catch (e) { console.log('There was an error, but I will not throw it.'); console.log('The error\'s message was: ' + e.message) } } function funcThatThrowsError() { throw new TypeError('I am a TypeError.'); } runWithoutThrowing(funcThatThrowsError);
如果使用者傳遞給函式 runWithoutThrowing
的引數丟擲了一個錯誤物件, 上面的程式碼能正常捕獲錯誤. 然後, 如果是丟擲一個字串, 就會碰到一些問題了:
function runWithoutThrowing(func) { try { func(); } catch (e) { console.log('There was an error, but I will not throw it.'); console.log('The error\'s message was: ' + e.message) } } function funcThatThrowsString() { throw 'I am a String.'; } runWithoutThrowing(funcThatThrowsString);
現在第二個 console.log
會輸出undefined. 這看起來不是很重要, 但如果你需要確保 Error
物件有一個特定的屬性或者用另一種方式來處理 Error
物件的特定屬性(例如 Chai的throws斷言的做法), 你就得做大量的工作來確保程式的正確執行.
同時, 如果丟擲的不是 Error
物件, 也就獲取不到 stack
屬性.
Errors 也可以被作為其它物件, 你也不必丟擲它們, 這也是為什麼大多數回撥函式把 Errors 作為第一個引數的原因. 例如:
const fs = require('fs'); fs.readdir('/example/i-do-not-exist', function callback(err, dirs) { if (err instanceof Error) { // `readdir` will throw an error because that directory does not exist // We will now be able to use the error object passed by it in our callback function console.log('Error Message: ' + err.message); console.log('See? We can use Errors without using try statements.'); } else { console.log(dirs); } });
最後, Error
物件也可以用於 rejected promise, 這使得很容易處理 rejected promise:
new Promise(function(resolve, reject) { reject(new Error('The promise was rejected.')); }).then(function() { console.log('I am an error.'); }).catch(function(err) { if (err instanceof Error) { console.log('The promise was rejected with an error.'); console.log('Error Message: ' + err.message); } });
處理堆疊
這一節是針對支援 Error.captureStackTrace
的執行環境, 例如Nodejs.
Error.captureStackTrace
的第一個引數是 object
, 第二個可選引數是一個 function
. Error.captureStackTrace
會捕獲堆疊資訊, 並在第一個引數中建立 stack
屬性來儲存捕獲到的堆疊資訊. 如果提供了第二個引數, 該函式將作為堆疊呼叫的終點. 因此, 捕獲到的堆疊資訊將只顯示該函式呼叫之前的資訊.
用下面的兩個demo來解釋一下. 第一個, 僅將捕獲到的堆疊資訊存於一個普通的物件之中:
const myObj = {}; function c() { } function b() { // Here we will store the current stack trace into myObj Error.captureStackTrace(myObj); c(); } function a() { b(); } // First we will call these functions a(); // Now let's see what is the stack trace stored into myObj.stack console.log(myObj.stack); // This will print the following stack to the console: // at b (repl:3:7) <-- Since it was called inside B, the B call is the last entry in the stack // at a (repl:2:1) // at repl:1:1 <-- Node internals below this line // at realRunInThisContextScript (vm.js:22:35) // at sigintHandlersWrap (vm.js:98:12) // at ContextifyScript.Script.runInThisContext (vm.js:24:12) // at REPLServer.defaultEval (repl.js:313:29) // at bound (domain.js:280:14) // at REPLServer.runBound [as eval] (domain.js:293:12) // at REPLServer.onLine (repl.js:513:10)
從上面的示例可以看出, 首先呼叫函式 a
(被壓入堆疊), 然後在 a
裡面呼叫函式 b
(被壓入堆疊且在a
之上), 然後在 b
中捕獲到當前的堆疊資訊, 並將其儲存到 myObj
中. 所以, 在控制檯輸出的堆疊資訊中僅包含了 a
和 b
的呼叫資訊.
現在, 我們給 Error.captureStackTrace
傳遞一個函式作為第二個引數, 看下輸出資訊:
const myObj = {}; function d() { // Here we will store the current stack trace into myObj // This time we will hide all the frames after `b` and `b` itself Error.captureStackTrace(myObj, b); } function c() { d(); } function b() { c(); } function a() { b(); } // First we will call these functions a(); // Now let's see what is the stack trace stored into myObj.stack console.log(myObj.stack); // This will print the following stack to the console: // at a (repl:2:1) <-- As you can see here we only get frames before `b` was called // at repl:1:1 <-- Node internals below this line // at realRunInThisContextScript (vm.js:22:35) // at sigintHandlersWrap (vm.js:98:12) // at ContextifyScript.Script.runInThisContext (vm.js:24:12) // at REPLServer.defaultEval (repl.js:313:29) // at bound (domain.js:280:14) // at REPLServer.runBound [as eval] (domain.js:293:12) // at REPLServer.onLine (repl.js:513:10) // at emitOne (events.js:101:20)
當將函式 b
作為第二個引數傳給 Error.captureStackTraceFunction
時, 輸出的堆疊就只包含了函式 b
呼叫之前的資訊(儘管 Error.captureStackTraceFunction
是在函式 d
中呼叫的), 這也就是為什麼只在控制檯輸出了 a
. 這樣處理方式的好處就是用來隱藏一些與使用者無關的內部實現細節.
參考
JavaScript Errors and Stack Traces in Depth
相關文章
- 深入理解 JavaScript 錯誤和堆疊追蹤JavaScript
- 利用Decorator和SourceMap優化JavaScript錯誤堆疊優化JavaScript
- 使用Error Stack跟蹤Oracle錯誤堆疊資訊ErrorOracle
- 淺析Node是如何進行錯誤處理的
- StackOverflowError堆疊溢位錯誤Error
- 通過錯誤堆疊資訊和原始碼分析錯誤來源原始碼
- 淺談前端錯誤處理前端
- javascript之處理Ajax錯誤JavaScript
- JavaScript的錯誤簡易處理JavaScript
- Go 錯誤堆疊資訊之 CockroachDB errors 庫GoError
- 【原創】mysql 錯誤緩衝堆疊薦MySql
- PHP錯誤處理和異常處理PHP
- SQL追蹤和事件追蹤SQL事件
- JavaScript 錯誤處理的最佳實踐JavaScript
- javascript中的錯誤處理機制JavaScript
- Golang 學習——error 錯誤處理淺談GolangError
- 淺談JavaScript錯誤JavaScript
- 如何優雅地檢視 JS 錯誤堆疊?JS
- VC++ 崩潰處理以及列印呼叫堆疊C++
- 淺出Vue 錯誤處理機制errorCaptured、errorHandlerVueErrorAPT
- 錯誤處理
- Python錯誤處理和異常處理(二)Python
- oracle追蹤誤操作DDLOracle
- 效能優化小冊 - 非同步堆疊追蹤:為什麼 await 勝過 Promise優化非同步AIPromise
- 流式處理框架storm淺析(下篇)框架ORM
- Linux 中斷處理淺析Linux
- JavaScript學習(2):物件、集合以及錯誤處理JavaScript物件
- ORA-12516: TNS: 監聽程式找不到符合協議堆疊要求的可用處理程'錯誤協議
- 六、函式、包和錯誤處理函式
- C++錯誤和異常處理C++
- 前端的水平線,錯誤處理和除錯前端除錯
- PHP 錯誤處理PHP
- php錯誤處理PHP
- Go 錯誤處理Go
- Swift錯誤處理Swift
- Zabbix錯誤處理
- mysqldump錯誤處理MySql
- Laravel/Lumen 自定義錯誤日誌格式過濾堆疊資訊Laravel