絕大多數程序只考慮了接口正常工作的場景，而用戶在使用我們的產品時遇到的各類異常，全都丟在看似 ok 的 try catch 中。如果沒有做好異常的兼容和兜底處理，會極大的影響用戶體驗，嚴重的還會帶來安全和資損風險。
如果想學習Java工程化、高性能及分佈式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群裡有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。
接口異常，通常可以分為以下三類：
- CGI 邏輯出錯。如調用方入參缺失類業務邏輯報錯；
- 服務不穩定。如服務器不穩定導致 nginx 各類 500、502，cgi 路徑調整導致的 404
- 用戶網絡環境差。如，網絡不穩定、網速慢、運營商劫持等
那麼，我們在寫代碼時，如何快速的模擬這些接口異常，做好程序的兼容處理呢？
今天向大家介紹網絡調試神器 whistle 的網絡異常調試方法，如果你還沒用過 whistle，請參考《8102 年的程序員不需要 Hosts 和 Fiddler》。
假設我們有以下前端頁面 index.html，放置在自己的本地路徑：
接下來，打開 whistle Rules 配置面板 http://127.0.0.1:8899/#rules ，配置模擬的 demo page 和 mock CGI：
*/mock file://({"code":0,"data":"success"}) # 配置 mock cgi 為模擬的 json 數據
example.com file:///Users/kaiye/Projects/Markdown/20181213/ # 配置任意域名到本地 demo 目錄，這裡注意替換成自己的路徑
打開 http://example.com ，正常邏輯下頁面展示出了綠色的 success ，現在我們開始加入一些網絡異常。
1、業務邏輯異常處理
例如 CGI 沒有返回 data 字段，而是返回了一個錯誤碼 code 和對應的 message，針對這種業務邏輯異常我們只需在第二個 then 中做好 code 值的判斷即可（注意，這裡的 code、message、data 只是示例，實際業務 CGI 中的 JSON 結構體的字段名很可能不同）：
fetch(`/mock?r=${Math.random()}`)
.then(response => response.json())
.then((v) => {
// 業務邏輯異常處理
if (v.code !== 0) {
return Promise.reject(new Error(`ERROR_LOGIC_CODE:${v.code}`));
}
document.getElementById('success').innerHTML = v.data;
})
.catch((err) => {
document.getElementById('fail').innerHTML = err.message;
});
相應的 whistle 配置如下：
*/mock file://({"code":12345,"message":"some_logic_error"}) # 模擬業務邏輯異常
2、服務器異常處理
如果想學習Java工程化、高性能及分佈式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群裡有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。
如果服務器直接拋出了 502 錯誤碼，我們希望代碼能給用戶提示的同時，再做一個異常上報。
fetch(`/mock?r=${Math.random()}`)
.then((response) => {
// 服務器異常處理
if (response.ok) {
return response.json();
}
return Promise.reject(new Error(`ERROR_STATUS_CODE:${response.status}`));
})
.then((v) => {
// 業務邏輯異常處理
if (v.code !== 0) {
return Promise.reject(new Error(`ERROR_LOGIC_CODE:${v.code}`));
}
document.getElementById('success').innerHTML = v.data;
})
.catch((err) => {
const [type, value] = err.message.split(':');
// 異常類型上報
console.log(type, value);
document.getElementById('fail').innerHTML = err.message;
});
通過 whistle 的模擬配置如下：
*/mock statusCode://502 # 模擬 HTTP 狀態碼異常
3、接口被劫持注入
如果 CGI 被運營商劫持注入，可能導致接口返回一個不合法的 JSON 結構，最前面的 response.json() 會拋異常，我們可以提前 catch 住：
fetch(`/mock?r=${Math.random()}`).then((response) => {
// 服務器異常處理
if (response.ok) {
return (
response
.json()
// 接口數據解碼異常處理
.catch(err => Promise.reject(new Error('ERROR_DECODE_JSON')))
);
}
return Promise.reject(new Error(`ERROR_STATUS_CODE:${response.status}`));
});
whistle 模擬配置如下：
*/mock file://(hijacking{"code":0,"data":"success"}) # 模擬接口被劫持注入 1
藉助 htmlAppend 和 values 配置，可以模擬更復雜的注入示例：
*/mock file://({"code":0,"data":"success"}) htmlAppend://{hijacking.html} # 模擬接口被劫持注入 2
```hijacking.html
```
4、用戶網絡不穩定
如果我們要模擬請求發出 10 秒後斷網或網絡不通的情況，可以通過 whistle 這樣配置：
*/mock reqDelay://10000 enable://abort # 模擬 10 秒超時後網絡不通
讓用戶苦苦等待 10 秒，再報錯的體驗太糟糕。我們可以封裝一個能配置超時時間的請求發送函數，同時把上面提到的錯誤異常都一起配置進來。
這樣，自定義的 myFetch 只需關注業務具體邏輯，針對不同的 catch error 做對應的處理。
除以上提到的協議命令字外，whistle 還支持 resSpeed 用於模擬低網速傳輸（單位：kb/s），tpl 協議則可以根據請求傳入參數來動態模擬不同的數據。在 Frames 面板，還可以對 WebSocket/Socket 請求進行暫停、延遲等網絡異常的模擬。
小程序 fetch API 實現
如果想學習Java工程化、高性能及分佈式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群裡有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。
最後，留一道思考題。
近來微信小程序開發非常火，小程序原生提供的 wx.request API 能用於發送 HTTPS 請求，請在它的基礎之上進行封裝，支持 promise 調用和 timeout 超時時間定義（小程序默認的請求超時定義在 app.json 中，不夠靈活），並針對以上提到的 HTTP 狀態碼異常、接口劫持注入、慢網絡、無網絡狀態等各種網絡異常進行兼容處理。
閱讀更多 Java的小本家 的文章
