99 的程式都沒有考慮的網路異常

本文由雲+社群發表

絕大多數程式只考慮了介面正常工作的場景，而使用者在使用我們的產品時遇到的各類異常，全都丟在看似 ok 的 try catch 中。如果沒有做好異常的相容和兜底處理，會極大的影響使用者體驗，嚴重的還會帶來安全和資損風險。

介面異常，通常可以分為以下三類：

那麼，我們在寫**時，如何快速的模擬這些介面異常，做好程式的相容處理呢？

假設我們有以下前端頁面 index.html，放置在自己的本地路徑：

複製**

接下來，開啟 whistle rules 配置面板，配置模擬的 demo page 和 mock cgi：

*/mock file://() # 配置 mock cgi 為模擬的 json 資料 example.com file:///users/kaiye/projects/markdown/20181213/ # 配置任意網域名稱到本地 demo 目錄，這裡注意替換成自己的路徑

複製**

開啟 example.com ，正常邏輯下頁面展示出了綠色的success，現在我們開始加入一些網路異常。

例如 cgi 沒有返回data字段，而是返回了乙個錯誤碼code和對應的message，針對這種業務邏輯異常我們只需在第二個then中做好 code 值的判斷即可（注意，這裡的 code、message、data 只是示例，實際業務 cgi 中的 json 結構體的欄位名很可能不同）：

fetch(`/mock?r=$`)
.then(response => response.json())
.then((v) => `));
}document.getelementbyid('success').innerhtml = v.data;
}).catch((err) => );
複製**

相應的 whistle 配置如下：

*/mock file://() # 模擬業務邏輯異常
複製**

如果伺服器直接丟擲了 502 錯誤碼，我們希望**能給使用者提示的同時，再做乙個異常上報。

fetch(`/mock?r=$`)
.then((response) => 
return
promise.reject(new
error(`error_status_code:$`));
}).then((v) => `));
}document.getelementbyid('success').innerhtml = v.data;
}).catch((err) => );
複製**

通過 whistle 的模擬配置如下：

*/mock statuscode://502 # 模擬 http 狀態碼異常

複製**

如果 cgi 被運營商劫持注入，可能導致介面返回乙個不合法的 json 結構，最前面的response.json()會拋異常，我們可以提前 catch 住：

fetch(`/mock?r=$`).then((response) => 
return
promise.reject(new
error(`error_status_code:$`));
});複製**

whistle 模擬配置如下：

*/mock file://(hijacking
) # 模擬介面被劫持注入 1
複製**

```hijacking.html```

複製**

如果我們要模擬請求發出 10 秒後斷網或網路不通的情況，可以通過 whistle 這樣配置：

*/mock reqdelay://10000 enable://abort # 模擬 10 秒超時後網路不通

複製**

讓使用者苦苦等待 10 秒，再報錯的體驗太糟糕。我們可以封裝乙個能配置超時時間的請求傳送函式，同時把上面提到的錯誤異常都一起配置進來。

複製**

這樣，自定義的myfetch只需關注業務具體邏輯，針對不同的 catch error 做對應的處理。

除以上提到的協議命令字外，**whistle 還支援 resspeed 用於模擬低網速傳輸（單位：kb/s），tpl 協議則可以根據請求傳入引數來動態模擬不同的資料。**在 frames 面板，還可以對 websocket/socket 請求進行暫停、延遲等網路異常的模擬。

最後，留一道思考題。

99 的程式都沒有考慮的網路異常

99 的程式都沒有考慮的網路異常

「忙得連寫blog的時間都沒有了」

RE 「忙得連寫blog的時間都沒有了」

99 的程式都沒有考慮的網路異常

99 的程式都沒有考慮的網路異常

「忙得連寫blog的時間都沒有了」

RE 「忙得連寫blog的時間都沒有了」

相關推薦