前言
程式設計時我們往往拿到的是業務流程正確的業務說明文件或規範,但實際開發中卻佈滿荊棘和例外情況,而這些例外中包含業務用例的例外,也包含技術上的例外。對於業務用例的例外我們別無它法,必須要求實施人員與使用者共同提供合理的解決方案;而技術上的例外,則必須由我們碼農們手刃之,而這也是我想記錄的內容。
我打算分成《前端魔法堂——異常不僅僅是try/catch》和《前端魔法堂——呼叫棧,異常例項中的寶藏》兩篇分別敘述內建/自定義異常類,捕獲執行時異常/語法異常/網路請求異常/PromiseRejection事件,什麼是呼叫棧和如何獲取呼叫棧的相關資訊。
是不是未出發就已經很期待呢?好吧,大家捉緊扶手,老司機要開車了^_^
概要
本篇將敘述如下內容:
- 異常還是錯誤?它會如何影響我們的程式碼?
- 內建異常型別有哪些?
- 動手寫自己的異常型別吧!
- 捕獲“同步程式碼”中的"執行時異常",用
try/catch
就夠了。 - "萬能"異常捕獲者
window.onerror
,真的萬能嗎? - Promise.reject也拋異常,怎麼辦?
- 404等網路請求異常真心要後之後覺嗎?
一.異常還是錯誤?它會如何影響我們的程式碼?
在學習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
這個祖先型別了,其他所有的內建異常類和自定義類都必須繼承它。而它的標準屬性和方法就以下這寥寥幾個而已
@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的建構函式簽名是這樣的
@constructor
@param {String=} message - 設定message屬性
@param {String=} fileName - 設定fileName屬性
@param {number=} lineNumber - 設定lineNUmber屬性
現在我們看看具體有哪些內建的異常型別吧!
- EvalError,呼叫
eval()
時發生的異常,已被廢棄只用於向後相容而已 - InternalError,JavaScript引擎內部異常,FireFox獨門提供的!
- RangeError,當函式實參越界時發生,如
Array
,Number.toExponential
,Number.toFixed
和Number.toPrecision
時入參非法時。 - ReferenceError,當引用未宣告的變數時發生
- SyntaxError,解析時發生語法錯誤
- TypeError,當值不是所期待的型別時,
null.f()
也報這個錯 - URIError,當傳遞一個非法的URI給全域性URI處理函式時發生,如
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實現如下
(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~)
- Chrome中對於跨域指令碼所報的異常,雖然onerror能夠捕獲,但統一報
Script Error
。若要得到正確的錯誤資訊,則要配置跨域資源共享CORS才可以。 window.onerror
實際上採用的事件冒泡的機制捕獲異常,並且在冒泡(bubble)階段時才觸發,因此像網路請求異常這些不會冒泡的異常是無法捕獲的。- Promise.reject產生的未被catch的異常,
window.onerror
也是無能為力。
六.Promise.reject也拋異常,怎麼辦?
通過Promise來處理複雜的非同步流程控制讓我們得心應手,但倘若其中出現異常或Promise例項狀態變為rejected時,會是怎樣一個狀況,我們又可以如何處理呢?
Promise是如何標識異常發生的?
Promise例項的初始化狀態是pending,而發生異常時則為rejected,而導致狀態從pending轉變為rejected的操作有
- 呼叫
Promise.reject
類方法 - 在工廠方法中呼叫
reject
方法 - 在工廠方法或then回撥函式中拋異常
// 方式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
專屬於Promise的頂層異常處理
若在異常發生前我們沒有呼叫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才會觸發該事件。
七.404等網路請求異常真心要後之後覺嗎?
也許我們都遇到<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