這篇文章帶大家來了解Javascript 的 try catch 語句，介紹一下try catch語句的 2 個作用，希望對大家有幫助！
程式是從上到下順序執行的，同時可以透過一些控制語句來改變執行的路線，受控制語句影響下，程式最終的執行路線就是控制流。
js 裡面的控制語句有 if、for、while、try catch 等，它們都會改變程式的方向。
程式是操作資料的，隨著程式的運行，也就是控制流的前進而改變的資料叫做資料流。
很明顯，資料流是依賴控制流的，程式分析裡面的資料流分析也是要先做控制流分析。
例如這樣一段程式碼：
const a = 1;
let b;
if (a === 1) {
b = '1111';
} else {
b = '2222';
}因為a 為1，所以會執行到b = '1111';，這就是控制流，也就是程式最終執行的程式碼，可以用來分析程式的走向，做一些死程式碼刪除之類的最佳化。
而隨著控制流的執行，b 會被賦值為 2222，這就是資料流，也就是值的變化的過程，可以用來分析某個語句的變數的值。
程式是針對不同資料做不同的處理，如果資料有錯誤，那麼處理程序也就沒法處理了，就會報錯，會中斷後續的控制流程。例如資料為空、資料格式不對等等。這時候就要透過 try catch 做錯誤處理，也叫異常處理。
我們做異常處理有兩個目的：
對出錯的邏輯做一些兜底處理。
例如參數解析有錯誤的時候，在 catch 裡賦一個預設值。這種錯誤處理之後就沒必要再報出來了。這種情況下 try catch 也是作為邏輯的一部分，相當於 if else。
對報的錯誤做更場景化的描述。
JS 的報錯是 JS 引擎拋出的，例如呼叫了一個 null 物件的方法會報 TypeError，使用了未宣告的變數會報 ReferenceError。而具體的Error 是在不同場景下報出的，就有不同的意義：
如果這個物件是來自使用者輸入的，那就是使用者輸入的有錯誤，如果這個物件是從服務端取得的，那就意味著服務端傳回的資料有錯誤。在不同的場景下，同一個 Error 會有更具體的意義，所以我們要做 try catch。然後拋出一個自訂的錯誤，包含有場景資訊的錯誤描述。
這點很多庫和框架做的都比較好，報出的錯都是有具體的場景信息，甚至還有解決方式，而且還有的通過錯誤編號做了管理，可以通過errorno來查詢解決方式。這種就是對錯誤做了自訂的處理。
而很多業務程式碼中報的錯就沒有做這種處理，是直接把原生 Error 給報出來了。我們會透過異常監控平台來收集一些 throw 到全局的錯誤，而這些錯誤往往都是比較原始的信息，雖然帶上了錯誤位置和堆疊，但還要通過看源碼來定位問題。
例如報了一個物件為空的錯誤，但是我怎麼知道這是什麼物件為空，會是什麼原因，怎麼解決，有沒有編號。
如果我們能夠對各種錯誤 catch 之後 throw 出一些具體場景的自訂錯誤，那是不是就好的多了。這點第三方函式庫都做得很好，而業務程式碼很少有人注重場景化的自訂錯誤。
當然，前端業務程式碼的使用者是透過介面來使用該軟體的，其實只要對各種錯誤做一些 UI 上的提示就可以。而函式庫的程式碼是給開發者用的，那麼就要對各種錯誤做場景化的描述，甚至給錯誤編號並給出解決方案。
但我覺得商業程式碼也應該像第三方函式庫程式碼那樣來對待錯誤，不要把沒有啥意義的原生錯誤報出來，而是報一些有具體含義的自訂錯誤，這樣排查和解決問題就會簡單很多。
不過雖然場景化的自訂錯誤可以更好的幫助排查問題，那也一定是建立在對該段程式碼可能報的錯誤有把握的情況下。要是自己報出的錯誤訊息和實際的錯誤原因不一樣，反而會增加檢驗問題的難度，不如把原生錯誤報出來。
程式執行的流程是控制流，受控制語句影響，執行的過程中會改變數據，資料的變化叫做資料流，控制流和資料流是程式分析裡面經常分析的兩個面向。
錯誤會中斷控制流，我們要對錯誤做一些處理，透過 try catch。
錯誤處理有兩個目的：
一個是做一些兜底的處理，相當於 if else，不需要再把錯誤報出來。
一個是做對原生的 JS 錯誤做場景化的描述，創建一個有更具體資訊的錯誤物件拋出。
這點很多庫做的很好，甚至還會給錯誤編號並給出解決方式。但業務程式碼其實很多只做了給用戶的 UI 上的回饋，沒有對拋出的錯誤做場景化的包裝。這就導致了錯誤監控平台收集到的錯誤都是比較原始的錯誤，需要查看原始碼來排查。如果也能像函式庫的程式碼一樣做一些場景化的錯誤包裝，統計和排查起問題來會容易很多，這點大多數 Javascript 工程師都沒做到。
更多程式相關知識，請造訪：程式設計影片！ ！
以上是深入淺析JS中的try catch語句，聊聊它的 2 個作用！的詳細內容。更多資訊請關注PHP中文網其他相關文章！
