網頁開發過程中,我們有時會遇到HTML頁面白屏的問題,即打開網頁時頁面顯示空白,沒有任何內容。這不僅令用戶困惑,也使開發者頭疼不已。本文將分享一些常見的HTML頁面白屏問題解決方法,幫助你快速解決這個問題,讓你的網頁煥然一新!
第一步:檢查HTML代碼
首先,我們需要檢查HTML代碼是否正確。常見的錯誤包括標簽未閉合、標簽嵌套錯誤等。這些錯誤可能會導致頁面無法正常顯示。因此,仔細檢查HTML代碼,確保沒有語法錯誤是解決白屏問題的第一步。
第二步:檢查CSS文件
HTML頁面的樣式通常由CSS文件控制。如果CSS文件中存在錯誤或者無法正常加載,可能會導致頁面白屏。我們可以通過以下步驟檢查CSS文件是否存在問題:
1、檢查CSS文件路徑是否正確:確保CSS文件的路徑正確,并且文件存在于指定的位置。可以通過瀏覽器開發者工具查看網絡面板,檢查CSS文件是否被成功加載。
2、檢查CSS文件語法錯誤:使用CSS驗證工具,如W3C CSS驗證服務,檢查CSS文件是否存在語法錯誤。如果存在錯誤,及時修復。
3、檢查CSS選擇器和樣式規則:檢查CSS文件中的選擇器和樣式規則是否正確。可能存在選擇器與HTML元素不匹配或樣式規則沖突的情況。可以通過逐個注釋掉樣式規則,逐步排查問題。
第三步:檢查JavaScript代碼
JavaScript代碼也可能導致頁面白屏。以下是檢查JavaScript代碼的步驟:
1、檢查JS文件路徑是否正確:與CSS文件類似,確保JS文件的路徑正確,并且文件存在于指定的位置。通過瀏覽器開發者工具查看控制臺面板,檢查是否有JS文件加載錯誤的提示信息。
2、檢查JS代碼語法錯誤:使用JS語法檢查工具,檢查JS代碼是否存在語法錯誤。如果有錯誤,及時修復。
3、檢查JS代碼邏輯錯誤:檢查JS代碼中的邏輯是否正確。可能存在變量未定義、函數未調用或者邏輯錯誤等問題。可以通過調試工具,如瀏覽器開發者工具中的調試器,逐步排查問題。
第四步:排查網絡請求問題
如果前面的步驟都沒有發現問題,那么可能是網絡請求出現了問題。以下是一些排查網絡請求問題的方法:
1、檢查網絡連接:確保你的設備已連接到互聯網,并且網絡連接穩定。
2、檢查資源加載狀態:通過瀏覽器開發者工具的網絡面板,檢查頁面中的資源加載狀態。可能存在資源加載失敗或者超時的情況,導致頁面白屏。
3、檢查服務器配置:如果你使用了服務器端腳本語言,如PHP,檢查服務器配置是否正確。可能存在服務器配置問題導致頁面無法正確渲染。
第五步:優化頁面性能
如果以上方法都沒有解決問題,那么可能是頁面性能問題導致白屏。以下是一些優化頁面性能的方法:
1、壓縮和合并文件:將CSS和JS文件進行壓縮和合并,減少文件的大小和數量,提高頁面加載速度。
2、使用緩存:利用瀏覽器緩存機制,將靜態資源進行緩存,減少服務器的請求次數,提高頁面加載速度。
3、異步加載資源:使用異步加載技術,如異步加載JS文件或使用延遲加載,減少頁面加載時間。
4、減少HTTP請求:減少頁面中的HTTP請求次數等。
結語:
通過以上五個步驟,我們可以逐步排查HTML頁面白屏問題,并解決它們。不同的問題可能需要不同的解決方法,因此需要耐心和細心地分析和排查。在開發過程中,我們也要時刻關注頁面性能,優化頁面加載速度,提高用戶體驗。
家好,我是 Echa。
本文將帶你了解 JavaScript 中常見的錯誤類型,處理同步和異步 JavaScript/Node.js 代碼中錯誤和異常的方式,以及錯誤處理最佳實踐!
JavaScript 中的錯誤是一個對象,在發生錯誤時會拋出該對象以停止程序。在 JavaScript 中,可以通過構造函數來創建一個新的通用錯誤:
const err = new Error("Error");
當然,也可以省略 new 關鍵字:
const err = Error("Error");
Error 對象有三個屬性:
例如,創建一個 TypeError 對象,該消息將攜帶實際的錯誤字符串,其 name 將是“TypeError”:
const wrongType = TypeError("Expected number");
wrongType.message; // 'Expected number'
wrongType.name; // 'TypeError'
堆棧跟蹤是發生異常或警告等事件時程序所處的方法調用列表:
它首先會打印錯誤名稱和消息,然后是被調用的方法列表。每個方法調用都說明其源代碼的位置和調用它的行。可以使用此數據來瀏覽代碼庫并確定導致錯誤的代碼段。此方法列表以堆疊的方式排列。它顯示了異常首先被拋出的位置以及它如何通過堆棧方法調用傳播。為異常實施捕獲不會讓它通過堆棧向上傳播并使程序崩潰。
對于 Error 對象,Firefox 還實現了一些非標準屬性:
JavaScript 中有一系列預定義的錯誤類型。只要使用者沒有明確處理應用程序中的錯誤,它們就會由 JavaScript 運行時自動選擇和定義。
JavaScript中的錯誤類型包括:
這些錯誤類型都是實際的構造函數,旨在返回一個新的錯誤對象。最常見的就是 TypeError。大多數時候,大部分錯誤將直接來自 JavaScript 引擎,例如 InternalError 或 SyntaxError。
JavaScript 提供了 instanceof 運算符可以用于區分異常類型:
try {
If (typeof x !== ‘number’) {
throw new TypeError(‘x 應是數字’);
} else if (x <= 0) {
throw new RangeError('x 應大于 0');
} else {
// ...
}
} catch (err) {
if (err instanceof TypeError) {
// 處理 TypeError 錯誤
} else if (err instanceof RangeError) {
// 處理 RangeError 錯誤
} else {
// 處理其他類型錯誤
}
}
下面來了解 JavaScript 中最常見的錯誤類型,并了解它們發生的時間和原因。
SyntaxError 表示語法錯誤。這些錯誤是最容易修復的錯誤之一,因為它們表明代碼語法中存在錯誤。由于 JavaScript 是一種解釋而非編譯的腳本語言,因此當應用程序執行包含錯誤的腳本時會拋出這些錯誤。在編譯語言的情況下,此類錯誤在編譯期間被識別。因此,在修復這些問題之前,不會創建應用程序二進制文件。
SyntaxError 發生的一些常見原因是:
TypeError 是 JavaScript 應用程序中最常見的錯誤之一,當某些值不是特定的預期類型時,就會產生此錯誤。
TypeError 發生的一些常見原因是:
ReferenceError 表示引用錯誤。當代碼中的變量引用有問題時,會發生 ReferenceError。可能忘記在使用變量之前為其定義一個值,或者可能試圖在代碼中使用一個不可訪問的變量。在任何情況下,通過堆棧跟蹤都可以提供充足的信息來查找和修復有問題的變量引用。
ReferenceErrors 發生的一些常見原因如下:
RangeError 表示范圍錯誤。當變量設置的值超出其合法值范圍時,將拋出 RangeError。它通常發生在將值作為參數傳遞給函數時,并且給定值不在函數參數的范圍內。當使用記錄不完整的第三方庫時,有時修復起來會很棘手,因為需要知道參數的可能值范圍才能傳遞正確的值。
RangeError 發生的一些常見場景如下:
URIError 表示 URI錯誤。當 URI 的編碼和解碼出現問題時,會拋出 URIError。JavaScript 中的 URI 操作函數包括:decodeURI、decodeURIComponent 等。如果使用了錯誤的參數(無效字符),就會拋出 URIError。
EvalError 表示 Eval 錯誤。當 eval() 函數調用發生錯誤時,會拋出 EvalError。不過,當前的 JavaScript 引擎或 ECMAScript 規范不再拋出此錯誤。但是,為了向后兼容,它仍然是存在的。
如果使用的是舊版本的 JavaScript,可能會遇到此錯誤。在任何情況下,最好調查在eval()函數調用中執行的代碼是否有任何異常。
InternalError 表示內部錯誤。在 JavaScript 運行時引擎發生異常時使用。它表示代碼可能存在問題也可能不存在問題。
InternalError 通常只發生在兩種情況下:
解決此錯誤最合適的方法就是通過錯誤消息確定原因,并在可能的情況下重構應用邏輯,以消除 JavaScript 引擎上工作負載的突然激增。
注意: 現代 JavaScript 中不會拋出 EvalError 和 InternalError。
雖然 JavaScript 提供了足夠的錯誤類型類列表來涵蓋大多數情況,但如果這些錯誤類型不能滿足要求,還可以創建新的錯誤類型。這種靈活性的基礎在于 JavaScript 允許使用 throw 命令拋出任何內容。
可以通過擴展 Error 類以創建自定義錯誤類:
class ValidationError extends Error {
constructor(message) {
super(message);
this.name = "ValidationError";
}
}
可以通過以下方式使用它:
throw ValidationError("未找到該屬性: name")
可以使用 instanceof 關鍵字識別它:
try {
validateForm() // 拋出 ValidationError 的代碼
} catch (e) {
if (e instanceof ValidationError) {
}
else {
}
}
很多人認為錯誤和異常是一回事。實際上,Error 對象只有在被拋出時才會成為異常。
在 JavaScript 中拋出異常,可以使用 throw 來拋出 Error 對象:
throw TypeError("Expected number");
或者:
throw new TypeError("Expected number");
來看一個簡單的例子:
function toUppercase(string) {
if (typeof string !== "string") {
throw TypeError("Expected string");
}
return string.toUpperCase();
}
在這里,我們檢查函數參數是否為字符串。如果不是,就拋出異常。
從技術上講,我們可以在 JavaScript 中拋出任何東西,而不僅僅是 Error 對象:
throw Symbol();
throw 33;
throw "Error!";
throw null;
但是,最好避免這樣做:要拋出正確的 Error 對象,而不是原語。
異常一旦拋出,就會在程序堆棧中冒泡,除非在某個地方被捕獲。
來看下面的例子:
function toUppercase(string) {
if (typeof string !== "string") {
throw TypeError("Expected string");
}
return string.toUpperCase();
}
toUppercase(4);
在瀏覽器或 Node.js 中運行此代碼,程序將停止并拋出錯誤:
這里還顯示了發生錯誤的確切行。這個錯誤就是一個堆棧跟蹤,有助于跟蹤代碼中的問題。堆棧跟蹤從下到上:
at toUppercase (<anonymous>:3:11)
at <anonymous>:9:1
toUppercase 函數在第 9 行調用,在第 3 行拋出錯誤。除了在瀏覽器的控制臺中查看此堆棧跟蹤之外,還可以在 Error 對象的 stack 屬性上訪問它。
介紹完這些關于錯誤的基礎知識之后,下面來看看同步和異步 JavaScript 代碼中的錯誤和異常處理。
同步代碼會按照代碼編寫順序執行。讓我們再看看前面的例子:
function toUppercase(string) {
if (typeof string !== "string") {
throw TypeError("Expected string");
}
return string.toUpperCase();
}
toUppercase(4);
在這里,引擎調用并執行 toUppercase,這一切都是同步發生的。 要捕獲由此類同步函數引發的異常,可以使用 try/catch/finally:
try {
toUppercase(4);
} catch (error) {
console.error(error.message);
} finally {
// ...
}
通常,try 會處理正常的路徑,或者可能進行的函數調用。catch 就會捕獲實際的異常,它接收 Error 對象。而不管函數的結果如何,finally 語句都會運行:無論它失敗還是成功,finally 中的代碼都會運行。
JavaScript 中的生成器函數是一種特殊類型的函數。它可以隨意暫停和恢復,除了在其內部范圍和消費者之間提供雙向通信通道。為了創建一個生成器函數,需要在 function 關鍵字后面加上一個 *:
function* generate() {
//
}
只要進入函數,就可以使用 yield 來返回值:
function* generate() {
yield 33;
yield 99;
}
生成器函數的返回值是一個迭代器對象。要從生成器中提取值,可以使用兩種方法:
以上面的代碼為例,要從生成器中獲取值,可以這樣做:
function* generate() {
yield 33;
yield 99;
}
const go = generate();
當我們調用生成器函數時,這里的 go 就是生成的迭代器對象。接下來,就可以調用 go.next() 來繼續執行:
function* generate() {
yield 33;
yield 99;
}
const go = generate();
const firstStep = go.next().value; // 33
const secondStep = go.next().value; // 99
生成器也可以接受來自調用者的值和異常。除了 next(),從生成器返回的迭代器對象還有一個 throw() 方法。使用這種方法,就可以通過向生成器中注入異常來停止程序:
function* generate() {
yield 33;
yield 99;
}
const go = generate();
const firstStep = go.next().value; // 33
go.throw(Error("Tired of iterating!"));
const secondStep = go.next().value; // never reached
要捕獲此類錯誤,可以使用 try/catch 將代碼包裝在生成器中:
function* generate() {
try {
yield 33;
yield 99;
} catch (error) {
console.error(error.message);
}
}
生成器函數也可以向外部拋出異常。 捕獲這些異常的機制與捕獲同步異常的機制相同:try/catch/finally。
下面是使用 for...of 從外部使用的生成器函數的示例:
function* generate() {
yield 33;
yield 99;
throw Error("Tired of iterating!");
}
try {
for (const value of generate()) {
console.log(value);
}
} catch (error) {
console.error(error.message);
}
輸出結果如下:
這里,try 塊中包含正常的迭代。如果發生任何異常,就會用 catch 捕獲它。
瀏覽器中的異步包括定時器、事件、Promise 等。異步世界中的錯誤處理與同步世界中的處理不同。下面來看一些例子。
上面我們介紹了如何使用 try/catch/finally 來處理錯誤,那異步中可以使用這些來處理錯誤嗎?先來看一個例子:
function failAfterOneSecond() {
setTimeout(() => {
throw Error("Wrong!");
}, 1000);
}
此函數在大約 1 秒后會拋出錯誤。那處理此異常的正確方法是什么?以下代碼是無效的:
function failAfterOneSecond() {
setTimeout(() => {
throw Error("Wrong!");
}, 1000);
}
try {
failAfterOneSecond();
} catch (error) {
console.error(error.message);
}
我們知道,try/catch是同步的,所以沒辦法這樣來處理異步中的錯誤。當傳遞給 setTimeout的回調運行時,try/catch 早已執行完畢。程序將會崩潰,因為未能捕獲異常。它們是在兩條路徑上執行的:
A: --> try/catch
B: --> setTimeout --> callback --> throw
我們可以監聽頁面中任何 HTML 元素的事件,DOM 事件的錯誤處理機制遵循與任何異步 Web API 相同的方案。
來看下面的例子:
const button = document.querySelector("button");
button.addEventListener("click", function() {
throw Error("error");
});
這里,在單擊按鈕后立即拋出了異常,我們該如何捕獲這個異常呢?這樣寫是不起作用的,也不會阻止程序崩潰:
const button = document.querySelector("button");
try {
button.addEventListener("click", function() {
throw Error("error");
});
} catch (error) {
console.error(error.message);
}
與前面的 setTimeout 例子一樣,任何傳遞給 addEventListener 的回調都是異步執行的:
Track A: --> try/catch
Track B: --> addEventListener --> callback --> throw
如果不想讓程序崩潰,為了正確處理錯誤,就必須將 try/catch 放到 addEventListener 的回調中。不過這樣做并不是最佳的處理方式,與 setTimeout 一樣,異步代碼路徑拋出的異常無法從外部捕獲,并且會使程序崩潰。
下面會介紹 Promises 和 async/await 是如何簡化異步代碼的錯誤處理的。
HTML 元素有許多事件處理程序,例如 onclick、onmouseenter、onchange 等。除此之外,還有 onerror,每當 <img> 標簽或 <script> 等 HTML 元素命中不存在的資源時,onerror 事件處理程序就會觸發。
來看下面的例子:
<body>
<img src="nowhere-to-be-found.png">
</body>
當訪問的資源缺失時,瀏覽器的控制臺就會報錯:
GET http://localhost:5000/nowhere-to-be-found.png
[HTTP/1.1 404 Not Found 3ms]
在 JavaScript 中,可以使用適當的事件處理程序“捕獲”此錯誤:
const image = document.querySelector("img");
image.onerror = function(event) {
console.log(event);
};
或者使用 addEventListener 來監聽 error 事件,當發生錯誤時進行處理:
const image = document.querySelector("img");
image.addEventListener("error", function(event) {
console.log(event);
});
此模式對于加載備用資源以代替丟失的圖像或腳本很有用。不過需要記住:onerror 與 throw 或 try/catch 是無關的。
下面來通過最上面的 toUppercase 例子看看 Promise 是如何處理錯誤的:
function toUppercase(string) {
if (typeof string !== "string") {
throw TypeError("Expected string");
}
return string.toUpperCase();
}
toUppercase(4);
對上面的代碼進行修改,不返回簡單的字符串或異常,而是分別使用 Promise.reject 和 Promise.resolve 來處理錯誤和成功:
function toUppercase(string) {
if (typeof string !== "string") {
return Promise.reject(TypeError("Expected string"));
}
const result = string.toUpperCase();
return Promise.resolve(result);
}
從技術上講,這段代碼中沒有任何異步的內容,但它可以很好地說明 Promise 的錯誤處理機制。
現在我們就可以在 then 中使用結果,并使用 catch 來處理被拒絕的 Promise:
toUppercase(99)
.then(result => result)
.catch(error => console.error(error.message));
輸出結果如下:
在 Promise 中,catch 是用來處理錯誤的。除了 catch 還有 finally,類似于 try/catch 中的finally。不管 Promise 結果如何,finally 都會執行:
toUppercase(99)
.then(result => result)
.catch(error => console.error(error.message))
.finally(() => console.log("Finally"));
輸出結果如下:
需要記住,任何傳遞給 then/catch/finally 的回調都是由微任務隊列異步處理的。 它們是微任務,優先于事件和計時器等宏任務。
作為拒絕 Promise 時的最佳實踐,可以傳入 error 對象:
Promise.reject(TypeError("Expected string"));
這樣,在整個代碼庫中保持錯誤處理的一致性。 其他團隊成員總是可以訪問 error.message,更重要的是可以檢查堆棧跟蹤。
除了 Promise.reject 之外,還可以通過拋出異常來退出 Promise 執行鏈。來看下面的例子:
Promise.resolve("A string").then(value => {
if (typeof value === "string") {
throw TypeError("Expected number!");
}
});
這里使用 字符串來 resolve 一個 Promise,然后執行鏈立即使用 throw 斷開。為了停止異常的傳播,可以使用 catch 來捕獲錯誤:
Promise.resolve("A string")
.then(value => {
if (typeof value === "string") {
throw TypeError("Expected number!");
}
})
.catch(reason => console.log(reason.message));
這種模式在 fetch 中很常見,可以通過檢查 response 對象來查找錯誤:
fetch("https://example-dev/api/")
.then(response => {
if (!response.ok) {
throw Error(response.statusText);
}
return response.json();
})
.then(json => console.log(json));
這里的異常可以使用 catch 來攔截。 如果失敗了,并且沒有攔截它,異常就會在堆棧中向上冒泡。這本身并沒有什么問題,但不同的環境對未捕獲的拒絕有不同的反應。
例如,Node.js 會讓任何未處理 Promise 拒絕的程序崩潰:
DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
所以,最好去捕獲錯誤。
對于計時器或事件,不能捕獲回調拋出的異常。上面有一個例子:
function failAfterOneSecond() {
setTimeout(() => {
throw Error("Error");
}, 1000);
}
// 不生效
try {
failAfterOneSecond();
} catch (error) {
console.error(error.message);
}
我們可以使用 Promise 來包裝計時器:
function failAfterOneSecond() {
return new Promise((_, reject) => {
setTimeout(() => {
reject(Error("Error"));
}, 1000);
});
}
這里通過 reject 捕獲了一個 Promise 拒絕,它帶有一個 error 對象。此時就可以用 catch 來處理異常了:
failAfterOneSecond().catch(reason => console.error(reason.message));
這里使用 value 作為 Promise 的返回值,使用 reason 作為拒絕的返回對象。
Promise.all 方法接受一個 Promise 數組,并返回所有解析 Promise 的結果數組:
const promise1 = Promise.resolve("one");
const promise2 = Promise.resolve("two");
Promise.all([promise1, promise2]).then((results) => console.log(results));
// 結果: ['one', 'two']
如果這些 Promise 中的任何一個被拒絕,Promise.all 將拒絕并返回第一個被拒絕的 Promise 的錯誤。
為了在 Promise.all 中處理這些情況,可以使用 catch:
const promise1 = Promise.resolve("good");
const promise2 = Promise.reject(Error("Bad"));
const promise3 = Promise.reject(Error("Bad+"));
Promise.all([promise1, promise2, promise3])
.then(results => console.log(results))
.catch(error => console.error(error.message));
如果想要運行一個函數而不考慮 Promise.all 的結果,可以使用 finally:
Promise.all([promise1, promise2, promise3])
.then(results => console.log(results))
.catch(error => console.error(error.message))
.finally(() => console.log("Finally"));
Promise.any 和 Promise.all 恰恰相反。Promise.all 如果某一個失敗,就會拋出第一個失敗的錯誤。而 Promise.any 總是返回第一個成功的 Promise,無論是否發生任何拒絕。
相反,如果傳遞給 Promise.any 的所有 Promise 都被拒絕,那產生的錯誤就是 AggregateError。 來看下面的例子:
const promise1 = Promise.reject(Error("Error"));
const promise2 = Promise.reject(Error("Error+"));
Promise.any([promise1, promise2])
.then(result => console.log(result))
.catch(error => console.error(error))
.finally(() => console.log("Finally"));
輸出結果如下:
這里用 catch 處理錯誤。AggregateError 對象具有與基本錯誤相同的屬性,外加一個 errors 屬性:
const promise1 = Promise.reject(Error("Error"));
const promise2 = Promise.reject(Error("Error+"));
Promise.any([promise1, promise2])
.then(result => console.log(result))
.catch(error => console.error(error.errors))
.finally(() => console.log("Finally"));
此屬性是一個包含所有被拒絕的錯誤信息的數組:
Promise.race 接受一個 Promise 數組,并返回第一個成功的 Promise 的結果:
const promise1 = Promise.resolve("one");
const promise2 = Promise.resolve("two");
Promise.race([promise1, promise2]).then(result =>
console.log(result)
);
// 結果:one
那如果有被拒絕的 Promise,但它不是傳入數組中的第一個呢:
const promise1 = Promise.resolve("one");
const rejection = Promise.reject(Error("Bad"));
const promise2 = Promise.resolve("two");
Promise.race([promise1, rejection, promise2]).then(result =>
console.log(result)
);
// 結果:one
這樣結果還是 one,不會影響正常的執行。
如果被拒絕的 Promise 是數組的第一個元素,則 Promise.race 拒絕,就必須要必須捕獲拒絕:
const promise1 = Promise.resolve("one");
const rejection = Promise.reject(Error("Bad"));
const promise2 = Promise.resolve("two");
Promise.race([rejection, promise1, promise2])
.then(result => console.log(result))
.catch(error => console.error(error.message));
// Bad
Promise.allSettled 是 ECMAScript 2020 新增的 API。它和 Promise.all 類似,不過不會被短路,也就是說當Promise全部處理完成后,可以拿到每個 Promise 的狀態, 而不管其是否處理成功。
來看下面的例子:
const promise1 = Promise.resolve("Good!");
const promise2 = Promise.reject(Error("Bad!"));
Promise.allSettled([promise1, promise2])
.then(results => console.log(results))
.catch(error => console.error(error))
.finally(() => console.log("Finally"));
這里向 Promise.allSettled 傳遞了一個包含兩個 Promise 的數組:一個已解決,另一個已拒絕。
輸出結果如下:
JavaScript 中的 async/await 表示異步函數,用同步的方式去編寫異步,可讀性更好。
下面來改編上面的同步函數 toUppercase,通過將 async 放在 function 關鍵字之前將其轉換為異步函數:
async function toUppercase(string) {
if (typeof string !== "string") {
throw TypeError("Expected string");
}
return string.toUpperCase();
}
只需在 function 前加上 async 前綴,就可以讓函數返回一個 Promise。這意味著我們可以在函數調用之后鏈式調用 then、catch 和 finally:
toUppercase("hello")
.then(result => console.log(result))
.catch(error => console.error(error.message))
.finally(() => console.log("Always runs!"));
當從 async 函數中拋出異常時,異常會成為底層 Promise 被拒絕的原因。任何錯誤都可以從外部用 catch 攔截。
除此之外,還可以使用 try/catch/finally 來處理錯誤,就像在同步函數中一樣。
例如,從另一個函數 consumer 中調用 toUppercase,它方便地用 try/catch/finally 包裝了函數調用:
async function toUppercase(string) {
if (typeof string !== "string") {
throw TypeError("Expected string");
}
return string.toUpperCase();
}
async function consumer() {
try {
await toUppercase(98);
} catch (error) {
console.error(error.message);
} finally {
console.log("Finally");
}
}
consumer();
輸出結果如下:
JavaScript 中的異步生成器是能夠生成 Promise 而不是簡單值的生成器函數。它將生成器函數與異步相結合,結果是一個生成器函數,其迭代器對象向消費者公開一個 Promise。
要創建一個異步生成器,需要聲明一個帶有星號 * 的生成器函數,前綴為 async:
async function* asyncGenerator() {
yield 33;
yield 99;
throw Error("Bad!"); // Promise.reject
}
因為異步生成器是基于 Promise,所以同樣適用 Promise 的錯誤處理規則,在異步生成器中,throw 會導致 Promise 拒絕,可以用 catch 攔截它。
要想從異步生成器處理 Promise,可以使用 then:
const go = asyncGenerator();
go.next().then(value => console.log(value));
go.next().then(value => console.log(value));
go.next().catch(reason => console.error(reason.message));
輸出結果如下:
也使用異步迭代 for await...of。 要使用異步迭代,需要用 async 函數包裝 consumer:
async function* asyncGenerator() {
yield 33;
yield 99;
throw Error("Bad"); // Promise.reject
}
async function consumer() {
for await (const value of asyncGenerator()) {
console.log(value);
}
}
consumer();
與 async/await 一樣,可以使用 try/catch 來處理任何異常:
async function* asyncGenerator() {
yield 33;
yield 99;
throw Error("Bad"); // Promise.reject
}
async function consumer() {
try {
for await (const value of asyncGenerator()) {
console.log(value);
}
} catch (error) {
console.error(error.message);
}
}
consumer();
輸出結果如下:
從異步生成器函數返回的迭代器對象也有一個 throw() 方法。在這里對迭代器對象調用 throw() 不會拋出異常,而是 Promise 拒絕:
async function* asyncGenerator() {
yield 33;
yield 99;
yield 11;
}
const go = asyncGenerator();
go.next().then(value => console.log(value));
go.next().then(value => console.log(value));
go.throw(Error("Reject!"));
go.next().then(value => console.log(value));
輸出結果如下:
可以通過以下方式來捕獲錯誤:
go.throw(Error("Let's reject!")).catch(reason =>
console.error(reason.message)
);
我們知道,迭代器對象的 throw() 是在生成器內部發送異常的。所以還可以使用以下方式來處理錯誤:
async function* asyncGenerator() {
try {
yield 33;
yield 99;
yield 11;
} catch (error) {
console.error(error.message);
}
}
const go = asyncGenerator();
go.next().then(value => console.log(value));
go.next().then(value => console.log(value));
go.throw(Error("Reject!"));
go.next().then(value => console.log(value));
Node.js 中的同步錯誤處理與 JavaScript 是一樣的,可以使用 try/catch/finally。
對于異步代碼,Node.js 強烈依賴兩個術語:
在回調模式中,異步 Node.js API 接受一個函數,該函數通過事件循環處理并在調用堆棧為空時立即執行。
來看下面的例子:
const { readFile } = require("fs");
function readDataset(path) {
readFile(path, { encoding: "utf8" }, function(error, data) {
if (error) console.error(error);
// data操作
});
}
這里可以看到回調中錯誤處理:
function(error, data) {
if (error) console.error(error);
// data操作
}
如果使用 fs.readFile 讀取給定路徑時出現任何錯誤,我們都會得到一個 error 對象。這時我們可以:
要想拋出異常,可以這樣做:
const { readFile } = require("fs");
function readDataset(path) {
readFile(path, { encoding: "utf8" }, function(error, data) {
if (error) throw Error(error.message);
// data操作
});
}
但是,與 DOM 中的事件和計時器一樣,這個異常會使程序崩潰。 使用 try/catch 停止它的嘗試將不起作用:
const { readFile } = require("fs");
function readDataset(path) {
readFile(path, { encoding: "utf8" }, function(error, data) {
if (error) throw Error(error.message);
// data操作
});
}
try {
readDataset("not-here.txt");
} catch (error) {
console.error(error.message);
}
如果不想讓程序崩潰,可以將錯誤傳遞給另一個回調:
const { readFile } = require("fs");
function readDataset(path) {
readFile(path, { encoding: "utf8" }, function(error, data) {
if (error) return errorHandler(error);
// data操作
});
}
這里的 errorHandler 是一個簡單的錯誤處理函數:
function errorHandler(error) {
console.error(error.message);
// 處理錯誤:寫入日志、發送到外部logger
}
Node.js 中的大部分工作都是基于事件的。大多數時候,我們會與發射器對象和一些偵聽消息的觀察者進行交互。
Node.js 中的任何事件驅動模塊(例如 net)都擴展了一個名為 EventEmitter 的根類。EventEmitter 有兩個基本方法:on 和 emit。
下面來看一個簡單的 HTTP 服務器:
const net = require("net");
const server = net.createServer().listen(8081, "127.0.0.1");
server.on("listening", function () {
console.log("Server listening!");
});
server.on("connection", function (socket) {
console.log("Client connected!");
socket.end("Hello client!");
});
這里我們監聽了兩個事件:listening 和 connection。除了這些事件之外,事件發射器還公開一個錯誤事件,在出現錯誤時觸發。
如果這段代碼監聽的端口是 80,就會得到一個異常:
const net = require("net");
const server = net.createServer().listen(80, "127.0.0.1");
server.on("listening", function () {
console.log("Server listening!");
});
server.on("connection", function (socket) {
console.log("Client connected!");
socket.end("Hello client!");
});
輸出結果如下:
events.js:291
throw er;
^
Error: listen EACCES: permission denied 127.0.0.1:80
Emitted 'error' event on Server instance at: ...
為了捕獲它,可以為 error 注冊一個事件處理函數:
server.on("error", function(error) {
console.error(error.message);
});
這樣就會輸出:
listen EACCES: permission denied 127.0.0.1:80
最后,我們來看看處理 JavaScript 異常的最佳實踐!
錯處理的第一個最佳實踐就是不要過度使用“錯誤處理”。通常,我們會在外層處理錯誤,從內層拋出錯誤,這樣一旦出現錯誤,就可以更好地理解是什么原因導致的。
然而,開發人員常犯的錯誤之一是過度使用錯誤處理。有時這樣做是為了讓代碼在不同的文件和方法中看起來保持一致。但是,不幸的是,這些會對應用程序和錯誤檢測造成不利影響。
因此,只關注代碼中可能導致錯誤的地方,錯誤處理將有助于提高代碼健壯性并增加檢測到錯誤的機會。
盡管許多瀏覽器都遵循一個通用標準,但某些特定于瀏覽器的 JavaScript 實現在其他瀏覽器上卻失敗了。例如,以下語法僅適用于 Firefox:
catch(e) {
console.error(e.filename + ': ' + e.lineNumber);
}
因此,在處理錯誤時,盡可能使用跨瀏覽器友好的 JavaScript 代碼。
當發生錯誤時,我們應該得到通知以了解出了什么問題。這就是錯誤日志的用武之地。JavaScript 代碼是在用戶的瀏覽器中執行的。因此,需要一種機制來跟蹤客戶端瀏覽器中的這些錯誤,并將它們發送到服務器進行分析。
可以嘗試使用以下工具來監控并上報錯誤:
Node.js 環境支持使用中間件向服務端應用中添加功能。因此可以創建一個錯誤處理中間件。使用中間件的最大好處是所有錯誤都在一個地方集中處理。可以選擇啟用/禁用此設置以輕松進行測試。
以下是創建基本中間件的方法:
const logError = err => {
console.log("ERROR: " + String(err))
}
const errorLoggerMiddleware = (err, req, res, next) => {
logError(err)
next(err)
}
const returnErrorMiddleware = (err, req, res, next) => {
res.status(err.statusCode || 500)
.send(err.message)
}
module.exports = {
logError,
errorLoggerMiddleware,
returnErrorMiddleware
}
可以像下面這樣在應用中使用此中間件:
const { errorLoggerMiddleware, returnErrorMiddleware } = require('./errorMiddleware')
app.use(errorLoggerMiddleware)
app.use(returnErrorMiddleware)
現在可以在中間件內定義自定義邏輯以適當地處理錯誤。而無需再擔心在整個代碼庫中實現單獨的錯誤處理結構。
我們可能永遠無法涵蓋應用中可能發生的所有錯誤。因此,必須實施回退策略以捕獲應用中所有未捕獲的異常。
可以這樣做:
process.on('uncaughtException', error => {
console.log("ERROR: " + String(error))
// 其他處理機制
})
還可以確定發生的錯誤是標準錯誤還是自定義操作錯誤。根據結果,可以退出進程并重新啟動它以避免意外行為。
與異常不同的是,promise 拒絕不會拋出錯誤。因此,一個被拒絕的 promise 可能只是一個警告,這讓應用有可能遇到意外行為。因此,實現處理 promise 拒絕的回退機制至關重要。
可以這樣做:
const promiseRejectionCallback = error => {
console.log("PROMISE REJECTED: " + String(error))
}
process.on('unhandledRejection', callback)
默認情況下,Spring Boot提供了一個/error映射,以合理的方式處理所有錯誤,并且它在servlet容器中注冊為“全局”錯誤頁面。對于機器客戶端,它會生成一個JSON響應,其中包含錯誤、HTTP狀態和異常消息的詳細信息。對于瀏覽器客戶端,有一個“白標簽”錯誤視圖,它以HTML格式呈現相同的數據(要自定義它,只需要定義一個以error 為beanName的View bean對象)。
如果需要自定義默認的錯誤處理行為,可以通過設置server.error相應屬性。
要完全替換默認行為,可以實現ErrorController并注冊為Bean,或者添加ErrorAttributes類型的bean。
BasicErrorController可以用作自定義ErrorController的基類。如果想為新的內容類型添加處理程序,這一點尤其有用(默認情況是專門處理text/html,并為其他所有內容提供后備)。要做到這一點,請擴展BasicErrorController,添加一個帶有具有products屬性的@RequestMapping的公共方法,并創建一個新類型的bean。
從Spring Framework 6.0開始,支持RFC 7807 Problem Details。Spring MVC可以使用application/pproblem+json媒體類型生成自定義錯誤消息,如:
{
"type": "http://www.pack.com/users/666",
"title": "Unknown project",
"status": 404,
"detail": "xxxxx",
"instance": "/users/666"
}
可以通過將spring.mvc.problemdetails.enabled設置為true來啟用此支持。
還可以定義一個用@ControllerAdvice注釋的類,以自定義JSON格式輸出,如以下示例所示:
@RestControllerAdvice(basePackageClasses = SomeController.class)
public class MyControllerAdvice extends ResponseEntityExceptionHandler {
@ExceptionHandler(Exception.class)
public ResponseEntity<?> handleControllerException(HttpServletRequest request, Throwable ex) {
HttpStatus status = getStatus(request);
return new ResponseEntity<>(new MyErrorBody(status.value(), ex.getMessage()), status);
}
private HttpStatus getStatus(HttpServletRequest request) {
Integer code = (Integer) request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);
HttpStatus status = HttpStatus.resolve(code);
return (status != null) ? status : HttpStatus.INTERNAL_SERVER_ERROR;
}
}
如果要顯示給定狀態代碼的自定義HTML錯誤頁面,可以將文件添加到/error目錄中。錯誤頁面可以是靜態HTML(即添加到任何靜態資源目錄下),也可以使用模板構建。文件的名稱應該是確切的狀態代碼或序列掩碼。
例如,要將404映射到靜態HTML文件,目錄結構如下:
src/
+- main/
+- java/
| + <source code>
+- resources/
+- public/
+- error/
| +- 404.html
+- <other public assets>
要使用FreeMarker模板映射所有5xx錯誤,目錄結構如下:
src/
+- main/
+- java/
| + <source code>
+- resources/
+- templates/
+- error/
| +- 5xx.ftlh
+- <other templates>
對于更復雜的映射,還可以添加實現ErrorViewResolver接口的bean,如以下示例所示:
@Component
public class PackErrorViewResolver implements ErrorViewResolver {
@Override
public ModelAndView resolveErrorView(HttpServletRequest request, HttpStatus status, Map<String, Object> model) {
if (status == HttpStatus.INTERNAL_SERVER_ERROR) {
return new ModelAndView("error") ;
}
return null ;
}
}
對于不使用Spring MVC的應用程序,可以使用ErrorPageRegistrar接口直接注冊ErrorPages。這種抽象直接與底層嵌入式Servlet容器一起工作,即使沒有Spring MVC DispatcherServlet也能工作。
@Configuration
public class PackErrorPagesConfiguration {
@Bean
public ErrorPageRegistrar errorPageRegistrar() {
return this::registerErrorPages;
}
private void registerErrorPages(ErrorPageRegistry registry) {
registry.addErrorPages(new ErrorPage(HttpStatus.BAD_REQUEST, "/400"));
}
}
這里以Tomcat為例,SpringBoot內嵌tomcat容器會自動注冊TomcatServletWebServerFactory該類進行Tomcat容器的配置,這其中就包括將錯誤頁注冊到tomcat中。并且該類實現了ErrorPageRegistry接口,該類專門用來注冊錯誤頁。
public class TomcatServletWebServerFactory {
public WebServer getWebServer(...) {
Tomcat tomcat = new Tomcat();
// ...
prepareContext(...);
}
protected void prepareContext(...) {
// ...
configureContext(...)
}
protected void configureContext(...) {
// ...
// 獲取容器中定義的所有ErrorPage錯誤頁
for (ErrorPage errorPage : getErrorPages()) {
org.apache.tomcat.util.descriptor.web.ErrorPage tomcatErrorPage = new org.apache.tomcat.util.descriptor.web.ErrorPage();
tomcatErrorPage.setLocation(errorPage.getPath());
tomcatErrorPage.setErrorCode(errorPage.getStatusCode());
tomcatErrorPage.setExceptionType(errorPage.getExceptionName());
context.addErrorPage(tomcatErrorPage);
}
}
}
這些ErrorPage通過如下方式被添加到上面的TomcatServletWebServerFactory中
SpringBoot會注冊一個ErrorPageRegistrarBeanPostProcessor處理器
public class ErrorPageRegistrarBeanPostProcessor implements BeanPostProcessor, BeanFactoryAware {
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
// 上面說了TomcatServletWebServerFactory實現了ErrorPageRegistry接口
if (bean instanceof ErrorPageRegistry) {
postProcessBeforeInitialization((ErrorPageRegistry) bean);
}
return bean;
}
private void postProcessBeforeInitialization(ErrorPageRegistry registry) {
for (ErrorPageRegistrar registrar : getRegistrars()) {
registrar.registerErrorPages(registry);
}
}
private Collection<ErrorPageRegistrar> getRegistrars() {
if (this.registrars == null) {
// 獲取容器中的所有ErrorPageRegistrar
this.registrars = new ArrayList<>(
this.beanFactory.getBeansOfType(ErrorPageRegistrar.class, false, false).values());
this.registrars.sort(AnnotationAwareOrderComparator.INSTANCE);
this.registrars = Collections.unmodifiableList(this.registrars);
}
return this.registrars;
}
}
注意:自定義ErrorPageRegistrar時,我們可以通過實現Ordered接口控制優先級
以上是本篇文章的全部內容,希望對你有幫助。
完畢!!!
公眾號:Spring全家桶實戰案例源碼
*請認真填寫需求信息,我們會在24小時內與您取得聯系。