① 前端如何盡量正確地處理ajax的異常
如今前端領域是MVVM框架的天下，組件庫也層出不窮，但是，並沒有一個知名的組件庫提供ajax異常的成熟解決方案，所以今天我們就來研討一下，如何盡量正確地處理異常。
從業務上簡單說，凡是code不是200的，都是異常。這里code可以是HTTP狀態碼，也可以是響應體的code，就不細究了，反正本質沒差別。然後，根據code的不同，又可以細分成401 403 404 500等等。
如果你的後端夥伴以HTTP狀態碼表示404，以響應體code表示其他錯誤，而且你又無法勸說他們，那麼你應在axios的攔截器里把各種情況全考慮進去，比如：
超時很簡單，axios也支持，設定超時閾值即可。超時跟無響應的區別是，超時意味著HTTP三次握手成功，但是得不到響應體，瀏覽器知道介面是存在的，但是響應體又在規定時間內沒有拿到。無響應是根本無法HTTP握手，也就無法獲知介面存在。
處理超時，通常做法是在攔截器里重新請求一遍，還是超時的話就視為伺服器錯誤。
得不到響應又分成2種，可能是網斷了，也可能是伺服器停機了。
苛刻地說，你應分辨這2種情況，並給出不同的提示，畢竟網斷了，用戶可以尋找別的聯網方式，而伺服器停機了就給個重連按鈕，讓用戶有事沒事的嘗試重連一下。
關於解決方案，首先說，XHR對象無法區分到底斷網還是伺服器停機，axios對於2種情況都返回'Network Error'。在得到這個反饋之後，你接下來可以有這2種解決辦法：
你可以將 https://api.map..com/images/blank.gif 改成其他伺服器穩定且位元組小的圖片。或許你可以做一張幾位元組的圖片，傳到一個非常牛逼的CDN上。
MDN手冊： https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/connection
它不支持IE，就算你不在乎這一點，那麼它是不是一定準呢？對於需要登錄的VPN網路，它是否准呢？我也不知道，總體說，它真的不是最佳的方案。我推薦用方案1。
很簡單，分為3種：
通常，一個介面，只需要按照其中一種去處理即可，優先順序就是上面書寫順序。
容器內錯誤提示肯定是內容區的介面出錯才會出現。
處理方式：
局部報錯比較容易理解，比如一個List的介面出錯，那麼，上策是應當給這個容器盡量撐高到有內容時的高度，然後居中給一個錯誤圖標和錯誤描述。中策是不考慮有內容時候的高度，只讓錯誤提示和錯誤描述撐起一定高度即可。都不算錯。如果容器很小，比如就是一個3位數值，那麼用一個 - 表示錯誤也可以。
頁面整體報錯稍微復雜，比如一個左右結構的內容管理系統，前置介面有userInfo介面、全局字典介面、全局路由介面等，這些介面與眾不同的地方在於它們是基礎介面，它們出錯的話，網站乾脆就不能用，頁面骨架也是錯亂的，這種情況下可以有2種解決辦法：一是跳轉到專門的5xx報錯頁面，頁面中央有錯誤圖標、錯誤提示，以及「返回上一頁」的按鈕；二是用白板遮罩覆蓋瀏覽器視口，居中放一個錯誤圖標和錯誤文字以及「刷新頁面」的按鈕，本質是用一個fixed的遮罩壓住瀏覽器全部面積。用哪種方案都可。所以你要做的是決定哪些介面屬於全局報錯，哪些介面屬於局部報錯，並做不同的處理。
報錯內容：
根據ajax異常的分類，可能至少能分出3種：網路錯誤、伺服器宕機、伺服器錯誤。具體用什麼圖標和文字我就不多說了。
組件化：
容器內報錯應盡量組件化。該放返回上一頁或刷新按鈕的，一定要放按鈕。
排他性：
只要做了容器內報錯，就不要做另外報錯了。這也說明了一點，就是在axios攔截器里彈toast或者modal是愚蠢的方案，我在別的文章也提到過這種觀點。不做容器內報錯的情況，才應該考慮其他3種情況。
什麼樣的場景下使用容器隱藏？
比如頁面有一個角落顯示你的粉絲數、關注數、評論量……。如果有獲取到數據，則讓這個容器出現，沒有的話，則容器就保持隱藏。這一類場景往往應用於非主要內容，比如側邊欄的小內容塊。
由於這只適用於非主要內容，那麼主要內容也會有它自己的報錯，所以，你不必擔心用戶看不到「網路出錯」這類錯誤提示。
先簡單對比一下toast和modal。
很簡單，toast就是輕提示，不需要手動關閉，modal就是重提示，需要手動關閉。採用哪個，只要站在用戶角度思考問題就好了。比如有人說，異常應當用重提示。可以這么絕對化么？不可以。比如你在某個頁面點贊，提示你 「您已經點過贊了」 ，這用重提示嗎？肯定toast就夠了。同樣的，成功提示一定用輕提示嗎？比如提示 「感謝參與，工作人員將在3~5個工作日內聯系你」 ，這么長，能toast？能一閃而過？
什麼介面適用彈出提示？簡單說，只要跟UI顯示不相乾的，都最好是使用彈出提示。比如這幾種場景：
先說上傳數據斷網之類的錯誤，通常用modal，因為modal能夠攔截用戶動作，避免重復上傳，而且，還能給用戶足夠的時間讓用戶看清楚出錯原因，避免無謂的重試。
然後說數據內容錯誤，無論是表單提交，還是點個贊，錯誤提示一般用toast，畢竟用戶可能只是不小心填錯的，看一眼然後趕緊改正就好了。
最後說401錯誤，有2種做法，一是用modal，因為一般要強制用戶轉到登錄頁，但是轉之前也得讓用戶看明白為什麼要轉，所以可以先modal提示，點擊確定就跳轉到登錄頁；二是用toast，但是需要先跳轉，然後在登錄頁上提示toast「請先登錄」。
警告條
警告條是可關閉的、永久生命的、又不妨礙用戶繼續操作的彈出組件，一般在頁面頂部，或者在用戶操作區域的附近。什麼場景用警告條？
比如的MD編輯器，你只要輸入，就會自動給伺服器發送數據，頻率很快，有時候因為網路或者伺服器的問題，會出現保存失敗的可能性，這時候就會在頁面頂部出現一個比較長時間的警告條，告訴你保存失敗，但你依然可以繼續寫，什麼時候網路正常了，什麼時候toast才會自動消失，當然你也可以手動關閉它。
總之，toast、modal、警告條究竟什麼場合使用，要根據產品、業務具體而定，要注意優先使用容器內報錯和容器隱藏。
② java開發前台報錯 500 Internal Server Error
500Internal Server Error 為內部伺服器錯誤。
常見產生原因及解決辦法：
伺服器資源超載：即同一時間內處理器有太多的進程需要處理的時候，會出現500錯誤。
查到某個進程消耗過多資源，強制關閉這個進程。
2.文件許可權設置錯誤：500錯誤還有可能是對文件設置了不正確的許可權，如果在剛剛上傳文件後出現500錯誤，應該主要檢查文件許可權設置。
③ 前端錯誤Uncaught TypeError: Cannot read property 'length' of null錯誤怎麼處理
通過統計資料庫中的1000多個項目，我們發現在 JavaScript 中最常出現的錯誤有10個。下面會向大家介紹這些錯誤發生的原因以及如何防止。
1. Uncaught TypeError: Cannot Read Property
這是 JavaScript 開發人員最常遇到的錯誤。當你讀取一個屬性或調用一個未定義對象的方法時，Chrome 中就會報出這樣的錯誤。
導致這個錯誤發生的原因有很多，常見的一種情況是在渲染 UI 組件時，不正確地初始化狀態。我們來看一個真實的應用程序中發生這種情況的例子。
以上代碼有兩個重要方面：
一是組件的狀態（例如 this.state），在開始生命周期之前是 undefined 狀態。
二是當通過非同步的方式獲取數據時，無論是在構造函數中 componentWillMount 中，還是在構造函數中提取 componentDidMount，組件在數據載入之前至少會渲染一次。當檢測首次渲染時，會發現 this.state.items 是未定義的。此時就會出現一個錯誤 -「Uncaught TypeError: Cannot read property 『map』 of undefined" in the consol」。
解決的方法很簡單：在構造函數中使用合理的默認值進行狀態初始化。
2. TypeError: 『undefined』 Is Not an Object (evaluating...)
這是在 Safari 中讀取屬性或調用未定義對象上的方法時發生的錯誤，這與 Chrome 的上述錯誤基本相同，只是 Safari 使用不同的錯誤消息。
3. TypeError: Null Is Not an Object (evaluating...)
這是在 Safari 中讀取屬性或調用空對象上的方法時發生的錯誤。
在實際情況中，導致這種錯誤的原因之一是：在元素載入之前，就嘗試在 JavaScript 中使用 DOM 元素。這是因為 DOM API 對於空白的對象引用返回 null。
任何執行和處理 DOM 元素的 JS 代碼，都應該在創建 DOM 元素之後執行。JS 代碼按照 HTML 中的規定自上而下進行解釋。因此，如果在 DOM 元素之前存在標簽，則腳本標簽內的 JS 代碼就會在瀏覽器分析 HTML 頁面時執行。如果在載入腳本之前尚未創建 DOM 元素，就會出現這樣的錯誤。
在這個例子中，我們可以通過添加一個事件偵聽器來解決這個問題，事件偵聽器會在頁面准備就緒時通知我們。一旦 addEventListener 被觸發，該 init( ) 方法就可以使用 DOM 元素。
4. (unknown): Script Error
當未捕獲的 JavaScript 錯誤違背跨邊界原則時，就會發生腳本錯誤。例如，如果將 JavaScript 代碼託管在 CDN 上，則任何未被捕獲的錯誤（通過 window.onerror 處理程序發出的錯誤，而不是 try-catch 中捕獲到的錯誤）將僅報告為「腳本錯誤」。這是瀏覽器的一種安全措施，主要用於防止跨域傳遞數據的情況出現。
要獲取真實的錯誤消息，需要執行以下操作：
Access-Control-Allow-Origin
將
Access-Control-Allow-Origin 設置為 *， 表示可以從任何域正確訪問資源。* 如有必要，也可以用自己的域名進行替換，例如：
Access-Control-Allow-Origin: www.example.com。
以下是在各種環境中設置的一些示例：
在腳本標簽上設置crossorigin =「anonymous」
在你的 HTML 源代碼中，為每一個腳本設置
Access-Control-Allow-Origin，在設置 SCRIPT 標簽中，設置 crossorigin="anonymous"。在將 crossorigin 屬性添加到腳本標簽之前，請確保正在向腳本文件發送 header。在 Firefox 中，如果 crossorigin 屬性存在但 Access-Control-Allow-Origin 標題不存在，則腳本不會執行。
5. TypeError: Object Doesn』t Support Property
當調用未定義的方法時，IE 中會發生這樣的錯誤。
這相當於 Chrome 中的 「undefined』 is not a function」 錯誤。對於相同的邏輯錯誤，不同的瀏覽器可能會有不同的錯誤消息。
這是在 IE 的 Web 應用程序中使用 JavaScript 命名空間出現的一個常見問題。出現這種情況的絕大部分原因是IE無法將當前名稱空間內的方法綁定到this關鍵字。例如，如果你有 JS Rollbar 方法的命名空間 isAwesome。通常，如果位於 Rollbar 命名空間內，則可以使用以下語法調用該 isAwesome 方法：
6. TypeError: 『undefined』 Is Not a Function
當調用未定義的函數時，Chrome 中就會發生這樣的錯誤。
執行上面的代碼會導致以下錯誤：「Uncaught TypeError: undefined is not a function。」 發生以上錯誤的原因是，當你調用 setTimeout( ) 時，實際上是在調用 window.setTimeout( )，傳遞給 setTimeout( ) 的匿名函數是在窗口對象的上下文中定義的，而該窗口對象沒有 clearBoard( ) 方法。
符合舊版瀏覽器的解決方案是以變數的方式簡單地將引用保存在 this 中，然後通過閉包繼承。