編程時咱們每每拿到的是業務流程正確的業務說明文檔或規範,但實際開發中卻佈滿荊棘和例外狀況,而這些例外中包含業務用例的例外,也包含技術上的例外。對於業務用例的例外咱們別無它法,必需要求實施人員與用戶共同提供合理的解決方案;而技術上的例外,則必須由咱們碼農們手刃之,而這也是我想記錄的內容。
我打算分紅《前端魔法堂——異常不只僅是try/catch》和《前端魔法堂——調用棧,異常實例中的寶藏》兩篇分別敘述內置/自定義異常類,捕獲運行時異常/語法異常/網絡請求異常/PromiseRejection事件,什麼是調用棧和如何獲取調用棧的相關信息。
是否是未出發就已經很期待呢?好吧,你們捉緊扶手,老司機要開車了^_^javascript
本篇將敘述以下內容:html
try/catch
就夠了。window.onerror
,真的萬能嗎? 在學習Java時咱們會被告知異常(Exception)和錯誤(Error)是不同的,異常是不會致使進程終止從而能夠被修復(try/catch),但錯誤將會致使進程終止所以不能被修復。當對於JavaScript而言,咱們要面對的僅僅有異常(雖然異常類名爲Error或含Error字樣),異常的出現不會致使JavaScript引擎崩潰,最多就是讓當前執行的任務終止而已。
上面說到異常的出現最多就是讓當前執行的任務終止,究竟是什麼意思呢?這裏就涉及到Event Loop的原理了,下面我嘗試用代碼大體說明吧。前端
<script> // 1.當前代碼塊將做爲一個任務壓入任務隊列中,JavaScript線程會不斷地從任務隊列中提取任務執行; // 2.當任務執行過程當中報異常,且異常沒有捕獲處理,則會一路沿着調用棧從頂到底拋出,最終終止當前任務的執行; // 3.JavaScript線程會繼續從任務隊列中提取下一個任務繼續執行。 function a(){throw Error("test")} function b(){a()} b() console.log("永遠不會執行!") </script> <script> // 下一個任務 console.log("你有你拋異常,我照樣執行!") </script>
說到內置異常類那麼必先提到的就是Error
這個祖先類型了,其餘全部的內置異常類和自定義類都必須繼承它。而它的標準屬性和方法就如下這寥寥幾個而已java
@prop {String} name - 異常名稱 @prop {String} message - 供人類閱讀的異常信息 @prop {Function} constructor - 類型構造器 @method toString():String - 輸出異常信息
因爲標準屬性實在太少,沒法提供更有效的信息供開發者定位異常發生的位置和重現事故現場,所以各瀏覽器廠家均手多多的本身增長些屬性,而後逐漸成了事實標準。編程
@prop {String} fileName - 異常發生的腳本URI @prop {number} lineNumber - 異常發生的行號 @prop {number} columnNumber - 異常發生的列號 @prop {String} stack - 異常發生時的調用棧信息,IE10及以上才支持 @method toSource():String - 異常發生的腳本內容
另外巨硬還新增如下兩個屬性跨域
@prop {String} description - 和message差很少 @prop {number} number - 異常類型的編號,巨硬爲每一個異常設置了一個惟一的編號
那麼如今我要實例化一個Error對象,只需調用Error()
或new Error()
便可;若想同時設置message,則改成Error("test")
或new Error("test")
。其實Error的構造函數簽名是這樣的promise
@constructor @param {String=} message - 設置message屬性 @param {String=} fileName - 設置fileName屬性 @param {number=} lineNumber - 設置lineNUmber屬性
如今咱們看看具體有哪些內置的異常類型吧!瀏覽器
eval()
時發生的異常,已被廢棄只用於向後兼容而已Array
,Number.toExponential
,Number.toFixed
和Number.toPrecision
時入參非法時。null.f()
也報這個錯decodeURIComponent('%')
,即decodeURIComponent
,decodeURI
,encodeURIComponent
,encodeURI
關於在StackOverflow上早有人討論如何自定義異常類型了參考
因而咱們順手拈來便可網絡
function MyError(message, fileName, lineNumber){ if (this instanceof MyError);else return new MyError(message, fileName, lineNumber) this.message = message || "" if (fileName){ this.fileName = fileName } if (lineNumber){ this.lineNumber = lineNumber } } var proto = MyError.prototype = Object.create(Error.prototype) proto.name = "MyError" proto.constructor = MyError
cljs實現以下app
(defn ^export MyError [& args] (this-as this (if (instance? MyError this) (let [ps ["message" "fileName" "lineNumber"] idxs (-> (min (count args) (count ps)) range)] (reduce (fn [accu i] (aset accu (nth ps i) (nth args i)) accu) this idxs)) (apply new MyError args)))) (def proto (aset MyError "prototype" (.create js/Object (.-prototype Error)))) (aset proto "name" "MyError") (aset proto "constructor" MyError)
try/catch
就夠了 爲了防止因爲異常的出現,致使正常代碼被略過的風險,咱們習慣採起try/catch
來捕獲並處理異常。
try{ throw Error("unexpected operation happen...") } catch (e){ console.log(e.message) }
cljs寫法
(try (throw (Error. "unexpected operation happen...") (catch e (println (.-message e)))))
不少時咱們會覺得這樣書寫就萬事大吉了,但其實try/catch
能且僅能捕獲「同步代碼」中的"運行時異常"。
1."同步代碼"就是說沒法獲取如setTimeout
、Promise
等異步代碼的異常,也就是說try/catch
僅能捕獲當前任務的異常,setTimeout
等異步代碼是在下一個EventLoop中執行。
// 真心捕獲不到啊親~! try{ setTimeout(function(){ throw Error("unexpected operation happen...") }, 0) } catch(e){ console.log(e) }
2."運行時異常"是指非SyntaxError,也就是語法錯誤是沒法捕獲的,由於在解析JavaScript源碼時就報錯了,還怎麼捕獲呢~~
// 非法標識符a->b,真心捕獲不到啊親~! try{ a->b = 1 } catch(e){ console.log(e) }
這時你們會急不可待地問:「異步代碼的異常咋辦呢?語法異常咋辦呢?」在解答上述疑問前,咱們先偏離一下,稍微挖挖throw
語句的特性。
throw
後面能夠跟什麼啊? 通常而言咱們會throw
一個Error或其子類的實例(如throw Error()
),其實咱們throw
任何類型的數據(如throw 1
,throw "test"
,throw true
等)。但即便能夠拋出任意類型的數據,咱們仍是要堅持拋出Error或其子類的實例。這是爲何呢?
try{ throw "unexpected operation happen..." } catch(e){ console.log(e) } try{ throw TypeError("unexpected operation happen...") } catch(e){ if ("TypeError" == e.name){ // Do something1 } else if ("RangeError" == e.name){ // Do something2 } }
緣由顯然易見——異常發生時提供信息越全越好,更容易追蹤定位重現問題嘛!
window.onerror
,真的萬能嗎? 在每一個可能發生異常的地方都寫上try/catch
顯然是不實際的(另外還存在性能問題),即便是羅嗦如Java咱們開發時也就是不斷聲明throws
,而後在頂層處理異常罷了。那麼,JavaScript中對應的頂層異常處理入口又在哪呢?木有錯,就是在window.onerror
。看看方法簽名吧
@description window.onerror處理函數 @param {string} message - 異常信息" @param {string} source - 發生異常的腳本的URI @param {number} lineno - 發生異常的腳本行號 @param {number} colno - 發生異常的腳本列號 @param {?Error} error - Error實例,Safari和IE10中沒有這個實參
這時咱們就能夠經過它捕獲除了try/catch
能捕獲的異常外,還能夠捕獲setTimeout
等的異步代碼異常,語法錯誤。
window.onerror = function(message, source, lineno, colno, error){ // Do something you like. } setTimeout(function(){ throw Error("oh no!") }, 0) a->b = 1
這樣就知足了嗎?還沒出大殺技呢——屏蔽異常、屏蔽、屏~~
只有onerror函數返回true
時,異常就不會繼續向上拋(不然繼續上拋就成了Uncaught Error了)。
// 有異常沒問題啊,由於我看不到^_^ window.onerror = function(){return true}
如今回到標題的疑問中,有了onerror就能夠捕獲全部異常了嗎?答案又是否認的(個人娘啊,還要折騰多久啊~0~)
Script Error
。若要獲得正確的錯誤信息,則要配置跨域資源共享CORS才能夠。window.onerror
實際上採用的事件冒泡的機制捕獲異常,而且在冒泡(bubble)階段時才觸發,所以像網絡請求異常這些不會冒泡的異常是沒法捕獲的。window.onerror
也是無能爲力。經過Promise來處理複雜的異步流程控制讓咱們駕輕就熟,但假若其中出現異常或Promise實例狀態變爲rejected時,會是怎樣一個情況,咱們又能夠如何處理呢?
Promise實例的初始化狀態是pending,而發生異常時則爲rejected,而致使狀態從pending轉變爲rejected的操做有
Promise.reject
類方法reject
方法// 方式1 Promise.reject("anything you want") // 方式2 new Promise(function(resolve, reject) { reject("anything you want") }) // 方式3 new Promise(function{ throw "anything you want" }) new Promise(function(r) { r(Error("anything you want" ) }).then(function(e) { throw e })
當Promise實例從pending轉變爲rejected時,和以前談論到異常同樣,要麼被捕獲處理,要麼繼續拋出直到成爲Uncaught(in promise) Error
爲止。
catch
掉 若在異常發生前咱們已經調用catch
方法來捕獲異常,那麼則相安無事
new Promise(function(resolve, reject){ setTimeout(reject, 0) }).catch(function(e){ console.log("catch") return "bingo" }).then(function(x){ console.log(x) }) // 回顯 bingo
若在異常發生前咱們沒有調用catch
方法來捕獲異常,仍是能夠經過window
的unhandledrejection
事件捕獲異常的
window.addEventListener("unhandledrejection", function(e){ // Event新增屬性 // @prop {Promise} promise - 狀態爲rejected的Promise實例 // @prop {String|Object} reason - 異常信息或rejected的內容 // 會阻止異常繼續拋出,不讓Uncaught(in promise) Error產生 e.preventDefault() })
catch
因爲Promise實例可異步訂閱其狀態變化,也就是能夠異步註冊catch處理函數,這時其實已經拋出Uncaught(in promise) Error
,但咱們依然能夠處理
var p = new Promise(function(resolve, reject){ setTimeout(reject, 0) }) setTimeout(function(){ p.catch(function(e){ console.log("catch") return "bingo" }) }, 1000)
另外,還能夠經過window
的rejectionhandled
事件監聽異步註冊catch處理函數的行爲
window.addEventListener("rejectionhandled", function(e){ // Event新增屬性 // @prop {Promise} promise - 狀態爲rejected的Promise實例 // @prop {String|Object} reason - 異常信息或rejected的內容 // Uncaught(in promise) Error已經拋出,因此這句毫無心義^_^ e.preventDefault() })
注意:只有拋出Uncaught(in promise) Error
後,異步catch纔會觸發該事件。
也許咱們都遇到<img src="./404.png">
報404網絡請求異常的狀況,而後測試或用戶保障怎麼哪一個哪一個圖標沒有顯示。其實咱們咱們能夠經過如下方式捕獲這類異常
window.addEventListener("error", function(e){ // Do something console.log(e.bubbles) // 回顯false }, true)
因爲網絡請求異常不會冒泡,所以必須在capture階段捕獲才能夠。但還有一個問題是這種方式沒法精確判斷異常的HTTP狀態是404仍是500等,所以仍是要配合服務端日誌來排查分析才能夠。
對異常和如何捕獲異常僅僅是前端智能監控中的一小撮知識點,敬請期待後續另外一小撮知識點《前端魔法堂——調用棧,異常實例中的寶藏》吧:D
尊重原創,轉載請註明來自:http://www.cnblogs.com/fsjohnhuang/p/7685144.html ^_^肥仔John
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypeError https://stackoverflow.com/questions/8504673/how-to-detect-on-page-404-errors-using-javascript