課程目標
- 認識 callback hell 與錯誤處理
課程內容
在非同步訓練一的課程，我們初步體驗到 callback hell 寫起來的感覺
其實，當年的工程師，面對的真正痛苦，比上次體驗到的更嚴重！
非同步任務，常常需要處理「任務失敗」的情況
比方說「主機回應超時」、「資料庫連線失敗」、「主機斷線」等等情況
按照 javascript 的慣例，就是多寫一個 callback function 處理這種情況
比方說函式可以設計成這樣
runAsyncTask(success, error)使用者只要分別傳進「成功後的處理」以及「失敗後的處理」即可
runAsyncTask(() => {
alert('執行成功！');
}, () => {
alert('執行失敗，請等等重新嘗試！');
});如果繼續拿 jquery 做範例，看起來會像這樣：
$.ajax({
url: url,
data: params,
success: (res) => {},
error: (res) => {},
});註1：他不是設計成兩個參數，而是物件的兩個屬性，但意思一樣
註2：沒辦法繼續用上次的 $.get()，他沒有設計錯誤處理的 callback。所以改用 $.ajax()
光看這樣可能還好，畢竟寫 javascript 就是很常到處寫 callback 傳來傳去
可是，你能想像連續呼叫多個 ajax 時，再加上錯誤處理機制，callback hell 會有多嚴重嗎！
來跟著作業，體驗一下，試著用當年的方式開發看看吧！
課後作業
這一次的作業，我們要延續「非同步 JS 訓練一：第1課」的內容，並且加上錯誤處理
https://codelove.tw/@howtomakeaturn/post/lqOkWq
請找出你上次寫的作業，把上次的三組 API，換成以下這三組
https://codelove.tw/fake-api/get-current-user-unstablehttps://codelove.tw/fake-api/get-orders-unstablehttps://codelove.tw/fake-api/get-order-details-unstable這三組 API 很不穩定，每組 API 都有 1/3 的機率會抓資料失敗！
實務上不可能有 API 爛成這樣，通常失敗率會在 1% 以下，這次是方便測試，我故意寫的 API
幾點注意事項如下：
- 不要使用現代的非同步寫法，請使用 callback hell 的寫法
- 使用
$.ajax()來呼叫 API - 使用
$.ajax()的success參數來處理成功的情況 - 使用
$.ajax()的error參數來處理失敗的情況 - 第一個 API 失敗時，請
alert('讀取用戶失敗，請稍後再試一次。'); - 第二個 API 失敗時，請
alert('讀取訂單列表失敗，請稍後再試一次。'); - 第三個 API 失敗時，請
alert('讀取訂單細節失敗，請稍後再試一次。');
寫完之後，你應該會看到有三層深度的巢狀 callback 傳遞！
而且比上次的情況還離譜！加上錯誤處理之後，整段 code 更加難以閱讀、維護！
這就是當年前端工程師，每天工作面臨的狀況！很悲慘吧！
做出以上功能，你就完成這次的課程目標了！
歡迎將作業成果，在下方留言，跟大家分享，讓大家給你一些回饋！
可以將每課學到的觀念、關鍵字，丟到網路上去搜尋、研究一下！
發問請在「討論專區」為主，或者分享學習筆記、寫學習心得！
貼文都會出現在個人檔案頁面，成為學習歷程、部落格紀錄！
未來面試時，分享給面試官看，會讓人知道你的積極程度！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
作業繳交
https://jsfiddle.net/hung19091/prmsd5ah/28/
這次的作業有大約71%的機率會跳錯誤訊息XD
另外，API網址需改為：
https://codelove.tw/fake-api/XXX