程式是從上到下順序執行的，同時可以通過一些控制語句來改變執行的路線，受控制語句影響下，程式最終的執行路線就是控制流。

裡面的控制語句有 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 做錯誤處理，也叫異常處理。

我們做異常處理有兩個目的：

1、對出錯的邏輯做一些兜底處理。

比如引數解析有錯誤的時候，在 catch 裡賦一個預設值。這種錯誤處理之後就沒必要再報出來了。這種情況下 try catch 也是作為邏輯的一部分，相當於 if else。

2、對報的錯做更場景化的描述。

JS 的www.cppcns.com

ReferenceError。而具體的 Error 是在不同場景下報出的，就有不同的含義：

如果這個物件是來自使用者輸入的，那就是使用者輸入的有錯誤，如果這個物件是從服務端獲取的，那就意味著服務端返回的資料有錯誤。在不同的場景下，同一個 EjsdvFoPFqNrror 會有更具體的含義，所以我們要做 try catch。然後丟擲一個自定http://www.cppcns.com義的錯誤，包含有場景資訊的錯誤描述。

這點很多庫和框架做的都比較好，報出的錯都是有具體的場景資訊，甚至還有解決方式，而且還有的通過錯誤編號做了管理，可以通過 errorno 來查詢解決方式。這種就是對錯誤做了自定義的處理。

而很多業務程式碼中報的錯就並沒有做這種處理，是直接把原生 Error 給報出來了。我們會通過異常監控平臺來收集一些www.cppcns.com throw 到全域性的錯誤，而這些錯誤往往都是比較原始的資訊，雖然帶上了錯誤位置和堆疊，但還要通過看原始碼來定位問題。

比如報了一個物件為空的錯誤，但是我怎麼知道這是什麼物件為空，會是什麼原因，怎麼解決，有沒有編號。

如果我們能夠對各種錯誤 catch 之後 throw 出一些具體場景的自定義錯誤，那是不是就好的多了。這點第三方庫都做得很好，而業務程式碼很少有人注重場景化的自定義錯誤。

當然，前端業務程式碼的使用者是通過介面來使用該軟體的，其實只要對各種錯誤做一些 UI 上的提示就可以。而庫的程式碼是給開發者用的，那麼就要對各種錯誤做場景化的描述，甚至給錯誤編號並給出解決方案。

但我覺得業務程式碼也應該像第三方庫程式碼那樣來對待錯誤，不要把沒有啥意義的原生錯誤報出來，而是報一些有具體含義的自定義錯誤，這樣排查和解決問題就會簡單很多。

不過雖然場景化的自定義錯誤可以更好的幫助排查問題，那也一定是建立在對該段程式碼可能報的錯誤有把握的情況下。要是自己報出的錯誤資訊和實際的錯誤原因不一樣，反而會增加排查問題的難度，還不如把原生錯誤報出來。

總結

程式執行的流程是控制流，受控制語句影響，執行的過程中會改變資料，資料的變化叫做資料流，控制流和資料流是程式分析裡面經常分析的兩個方面。

錯誤會中斷控制流，我們要對錯誤做一些處理，通過 try catch。

錯誤處理有兩個目的：

一個是做一些兜底的處理，相當於 if else，不需要再把錯誤報出來。

一個是做對原生的 JS 錯誤做場景化的描述，建立一個有更具體資訊的錯誤物件丟擲來。

這點很多庫做的很好，甚至還會給錯誤編號並給出解決方式。但業務程式碼其實很多隻做了給使用者的 UI 上的反饋，沒有對丟擲的錯誤做場景化的包裝。這就導致了錯誤監控平臺收集到的錯誤都是比較原始的錯誤，需要檢視原始碼來排查。如果也能像庫的程式碼那樣做一些場景化的錯誤包裝，統計和排查起問題來會容易很多，這點大多數 工程師都沒做到。

到此這篇關於script中try catch作用的文章就介紹到這了,更多相關Javascript中try catch作用內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！