我很困惑如何正確捕獲 JavaScript 例外。我有 Java Dev 的背景，我對錯誤處理的了解很多都來自于它。
我正在使用 sequelize 進行持久化，所以弄亂了它，我在網上找到了一個示例：
try {
//do sequelize stuff
} catch (error){
switch (error.name) {
case 'SequelizeUniqueConstraintError':
//do something
break;
case 'SequelizeValidationError':
//do something else
break;
default:
//do panic stuff
}
}
嗯...這鼓勵我看一下 sequelizer 的源代碼...
拋出的內容基本上是：
class UniqueConstraintError extends ValidationError {
constructor(options) {
options = options || {};
options.parent = options.parent || { sql: '' };
options.message = options.message || options.parent.message || 'Validation Error';
options.errors = options.errors || {};
super(options.message, options.errors);
this.name = 'SequelizeUniqueConstraintError';
this.errors = options.errors;
this.fields = options.fields;
this.parent = options.parent;
this.original = options.parent;
this.sql = options.parent.sql;
}
}
嗯...有趣....除了已經有型別之外，為什么例外會有名稱？所以我改變了我的代碼來處理型別本身而不是名稱，結果是這樣的：
try {
//do sequelize stuff
} catch (error){
if (error instanceof UniqueConstraintError) {
//do something
} else if (error instanceof ValidationError) {
//do something else
} else {
//do panic stuff
}
}
不用說，兩者都作業得很好。
我在這里缺少什么嗎？我是否遵循錯誤的教程？
Witch 解決方案將是處理現代 JavaScript 中拋出的多種可能例外的“卓越”解決方案？（女巫可能不一定是我在這里介紹的兩個中的任何一個）
謝謝。
uj5u.com熱心網友回復：
除了已經有型別之外，為什么例外還要有名稱？
出于與使用錯誤代碼相同的原因：它們可以很好地序列化并且不需要對類的參考。同樣在極少數情況下（應該避免），您最終可能會加載多個庫副本，這些副本定義了多個具有相同名稱的不同類。檢查.name字串仍然有效，instanceof僅在參考同一類時才有效。
為了處理現代 JavaScript 中拋出的多種可能的例外，哪種解決方案將是“卓越的”？
如果instanceof對您有用，那么使用它沒有任何問題 - 它非常地道。只是一些程式員更喜歡更具防御性的風格，這種風格在面對錯誤時更具彈性。使用字串常量有其自身的一系列問題，例如容易拼寫錯誤和 API 不兼容。
uj5u.com熱心網友回復：
檢查name財產的價值可能被認為更安全和/或更簡單，因為：
例如，一個實體
UniqueConstraintError也是一個實體，ValidationError因為前者擴展了后者，所以instanceof檢查的順序很關鍵，容易出錯。例如，
instanceof UniqueConstraintError如果false實體源自具有自己的全域范圍的不同執行背景關系（例如iframe.
如果您很高興這兩個原因都不相關，那么instanceof在我看來，這是更慣用的選擇，也是更好的選擇。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/430068.html
標籤：javascript 例外 ecmascript-6 续集.js
上一篇：從一個Fragment移動到另一個Fragment時，SwipeRefreshLayout被復制到另一個Fragment
下一篇：JSP如何在名稱屬性中連接值？