關(guān)于在Typescript中做錯誤處理的方式詳解

更新時間：2023年09月07日 09:09:16 作者：托兒所夜十三

錯誤處理是軟件工程重要的一部分,如果處理得當,它可以為你節(jié)省數(shù)小時的調(diào)試和故障排除時間,我發(fā)現(xiàn)了與錯誤處理相關(guān)的三大疑難雜癥：TypeScript的錯誤類型,變量范圍和嵌套,讓我們逐一深入了解它們帶來的撓頭問題,感興趣的朋友可以參考下

錯誤處理是軟件工程重要的一部分。如果處理得當，它可以為你節(jié)省數(shù)小時的調(diào)試和故障排除時間。我發(fā)現(xiàn)了與錯誤處理相關(guān)的三大疑難雜癥：

TypeScript 的錯誤類型
變量范圍
嵌套

讓我們逐一深入了解它們帶來的撓頭問題。

疑難雜癥一：Typescript 錯誤類型

在 JavaScript 中最常見的錯誤處理方式與大多數(shù)編程語言相同：

try {
  throw new Error('oh no!')
} catch (error) {
  console.dir(error)
}

最終會拋出這樣一個對象：

{
  message: 'oh no!'
  stack: 'Error: oh no!\n at <anonymous>:2:8'
}

這看起來非常簡單明了，那么 Typescript 又是怎樣的呢？首先你能看到的是在 Typescript 中使用 try/catch 并檢查錯誤類型是，得到的是 unknow。對于剛接觸 Typescript 的人來說遇到這種問題是非常撓頭的。解決這一問題的常用方法是簡單地將錯誤轉(zhuǎn)為其他類型，如下所示：

try {
  throw new Error('oh no!')
} catch (error) {
  console.log((error as Error).message)
}

這種方法可能適用于 99.9% 的捕獲錯誤。但為什么 TypeScript 的錯誤處理看起來很麻煩呢？原因在于無法推斷出 "error" 的類型，因為 try/catch 并不只捕獲錯誤，它還捕獲任何拋出的錯誤。在 JavaScript（和 TypeScript）中，幾乎可以拋出任何東西，如下所示：

try {
  throw undefined
} catch (error) {
  console.log((error as Error).message)
}

執(zhí)行這段代碼將導(dǎo)致在 "catch "代碼塊中拋出新的錯誤，這就沒有達到使用 try/catch 的目的：

Uncaught TypeError: Cannot read properties of undefined (reading 'message') at <anonymous>:4:20

問題產(chǎn)生的原因是 undefined 中不存在 message 屬性，從而導(dǎo)致在 catch 代碼塊中出現(xiàn) TypeError。在 JavaScript 中，只有兩個值會導(dǎo)致這個問題：undefined 和 null。

現(xiàn)在可能有人會問，有人拋出 undefined 或 null 的可能性有多大。雖然這種情況可能很少發(fā)生，但如果真的發(fā)生了，就會在代碼中引入意想不到的行為。此外，考慮到在 TypeScript 項目中通常會使用大量第三方包，如果其中一個包無意中拋出了一個不正確的值，也不足為奇。

這就是 TypeScript 將可拋類型設(shè)置為 unknow 的唯一原因嗎？乍一看，這可能只是一個罕見的邊緣情況，使用類型轉(zhuǎn)換是一個比較靠譜的解決方式。然而，事情并非如此簡單。雖然 undefined 和 null 是最具破壞性的情況，因為它們可能導(dǎo)致應(yīng)用程序崩潰，但其他值也可能被拋出。例如：

try {
  throw false
} catch (error) {
  console.log((error as Error).message)
}

這里的主要區(qū)別在于，它不會拋出 TypeError，而是直接返回 undefined。雖然這不會直接導(dǎo)致應(yīng)用程序崩潰，因此破壞性較小，但也會帶來其他問題，例如在日志中顯示未定義。此外，根據(jù)使用undefined 值的方式，它還可能間接導(dǎo)致應(yīng)用程序崩潰。請看下面的示例：

try {
  throw false
} catch (error) {
  console.log((error as Error).message.trim())
}

在這里，調(diào)用 undefined 上的 .trim() 將觸發(fā) TypeError，可能導(dǎo)致應(yīng)用程序崩潰。

從本質(zhì)上講，TypeScript 的目的是通過將 catchables 的類型指定為 unknow 來保護我們。這種方法讓開發(fā)人員有責任確定拋出值的正確類型，有助于防止出現(xiàn)運行時問題。

如下所示，您可以使用可選的鏈式操作符 (?.) 來保護您的代碼：

try {
  throw undefined
} catch (error) {
  console.log((error as Error)?.message?.trim?.())
}

雖然這種方法可以保護你的代碼，但它使用了兩個會使代碼維護復(fù)雜化的 TypeScript 特性：

類型轉(zhuǎn)換破壞了 TypeScript 的保障措施，即確保變量遵循其指定的類型。
在非可選類型上使用可選的鏈式操作符，在類型不匹配的情況下，如果有人遺漏了這些操作符，也不會引發(fā)任何錯誤。

更好的方法是利用 TypeScript 的類型保護。類型保護本質(zhì)上是一種函數(shù)，它能確保特定值與給定類型相匹配，并確認可以安全地按預(yù)期使用。下面是一個類型保護的示例，用于驗證捕獲的變量是否屬于 Error 類型：

export const isError = (value: unknown): value is Error =>
  !!value &&
  typeof value === 'object' &&
  'message' in value &&
  typeof value.message === 'string' &&
  'stack' in value &&
  typeof value.stack === 'string'

這種類型防護簡單明了。它首先確保值不是假的，這意味著它不會是 undefined 或 null。然后，它會檢查它是否是一個具有預(yù)期屬性的對象。

這種類型保護可以在代碼的任何地方重復(fù)使用，以驗證對象是否是 Error。下面是一個應(yīng)用示例：

const logError = (message: string, error: unknown): void => {
  if (isError(error)) {
    console.log(message, error.stack)
  } else {
    try {
      console.log(
        new Error(
          `Unexpected value thrown: ${
            typeof error === 'object' ? JSON.stringify(error) : String(error)
          }`
        ).stack
      )
    } catch {
      console.log(
        message,
        new Error(`Unexpected value thrown: non-stringifiable object`).stack
      )
    }
  }
}
try {
  const circularObject = { self: {} }
  circularObject.self = circularObject
  throw circularObject
} catch (error) {
  logError('Error while throwing a circular object:', error)
}

通過創(chuàng)建一個利用 isError 類型防護的 logError 函數(shù)，我們可以安全地記錄標準錯誤以及任何其他拋出的值。這對于排除意外問題特別有用。不過，我們需要謹慎，因為 JSON.stringify 也會拋出錯誤。通過將其封裝在自己的 try/catch 塊中，可以為對象提供更詳細的信息，而不僅僅是記錄其字符串表示 [object Object]。

此外，我們還可以檢索新 Error 對象實例化之前的堆棧跟蹤。這將包括拋出原始值的位置。雖然該方法不能直接提供拋出值的堆棧跟蹤，但它提供了拋出后的跟蹤，足以追溯到問題的源頭。

疑難雜癥二：變量范圍

范圍界定可能是錯誤處理中最常見的疑難雜癥，適用于 JavaScript 和 TypeScript。請看下面這個例子：

try {
  const fileContent = fs.readFileSync(filePath, 'utf8')
} catch {
  console.error(`Unable to load file`)
  return
}
console.log(fileContent)

在本例中，由于 fileContent 是在 try 代碼塊內(nèi)定義的，因此在該代碼塊外無法訪問。為了解決這個問題，你可能會想在 try 代碼塊之外定義變量：

let fileContent
try {
  fileContent = fs.readFileSync(filePath, 'utf8')
} catch {
  console.error(`Unable to load file`)
  return
}
console.log(fileContent)

這種方法并不理想。使用 let 而不是 const，就意味著變量是可變的，這會帶來潛在的錯誤。此外，它還會增加代碼的閱讀難度。

規(guī)避這一問題的方法之一是將 try/catch 代碼塊封裝在一個函數(shù)中：

const fileContent = (() => {
  try {
    return fs.readFileSync(filePath, 'utf8')
  } catch {
    console.error(`Unable to load file`)
    return
  }
})()
if (!fileContent) {
  return
}
console.log(fileContent)

雖然這種方法解決了可變性問題，但卻使代碼變得更加復(fù)雜。我們可以通過創(chuàng)建自己的可重用封裝函數(shù)來解決這個問題。

疑難雜癥三：嵌套

下面的示例演示了如何在可能出現(xiàn)多個錯誤的情況下使用新的 logError 函數(shù)：

export const doStuff = async (): Promise<void> => {
  try {
    const fetchDataResponse = await fetch('https://api.example.com/fetchData')
    const fetchDataText = await fetchDataResponse.text()
    if (!fetchDataResponse.ok) {
      throw new Error(
        `Unexpected response while fetching data. Status: ${fetchDataResponse.status} | Status text: ${fetchDataResponse.statusText} | Body: ${fetchDataText}`
      )
    }
    let fetchData
    try {
      fetchData = JSON.parse(fetchDataText) as unknown
    } catch {
      throw new Error(`Failed to parse fetched data response as JSON: ${fetchDataText}`)
    }
    if (
      !fetchData ||
      typeof fetchData !== 'object' ||
      !('data' in fetchData) ||
      !fetchData.data
    ) {
      throw new Error(
        `Fetched data is not in the expected format. Body: ${fetchDataText}`
      )
    }
    const storeDataResponse = await fetch('https://api.example.com/storeData', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(fetchData),
    })
    const storeDataText = await storeDataResponse.text()
    if (!storeDataResponse.ok) {
      throw new Error(
        `Unexpected response while storing data. Status: ${storeDataResponse.status} | Status text: ${storeDataResponse.statusText} | Body: ${storeDataText}`
      )
    }
  } catch (error) {
    logError('An error occurred:', error)
  }
}

你會發(fā)現(xiàn)調(diào)用的是 .text() API，而不是 .json()。因為 fetch 能調(diào)用這兩種方法中的一種。由于我們的目標是在 JSON 轉(zhuǎn)換失敗時顯示正文內(nèi)容，因此首先調(diào)用 .text()，然后手動還原為 JSON，確保在此過程中捕捉到任何錯誤。為避免出現(xiàn)以下隱含錯誤：

Uncaught SyntaxError: Expected property name or '}' in JSON at position 42

雖然錯誤提供的細節(jié)會使代碼更容易調(diào)試，但其有限的可讀性會給代碼維護帶來挑戰(zhàn)。try/catch 塊引起的嵌套增加了閱讀函數(shù)時的認知負擔。不過，有一種方法可以簡化代碼，如下所示：

export const doStuffV2 = async (): Promise<void> => {
  try {
    const fetchDataResponse = await fetch('https://api.example.com/fetchData')
    const fetchData = (await fetchDataResponse.json()) as unknown
    if (
      !fetchData ||
      typeof fetchData !== 'object' ||
      !('data' in fetchData) ||
      !fetchData.data
    ) {
      throw new Error('Fetched data is not in the expected format.')
    }
    const storeDataResponse = await fetch('https://api.example.com/storeData', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(fetchData),
    })
    if (!storeDataResponse.ok) {
      throw new Error(`Error storing data: ${storeDataResponse.statusText}`)
    }
  } catch (error) {
    logError('An error occurred:', error)
  }
}

這次重構(gòu)解決了嵌套問題，但也帶來了一個新問題：錯誤報告的粒度不夠。通過刪除檢查，變得更加依賴錯誤信息本身來理解問題。正如我們從一些 JSON.parse 錯誤中看到的那樣，這并不總能提供最好的顆粒度。

考慮到我們討論的所有的疑難雜癥，是否存在有效處理錯誤的最佳方法？

解決方案

應(yīng)該尋求一種比傳統(tǒng)的 try/catch 塊更優(yōu)越的錯誤處理方法。通過利用 TypeScript 的功能，我們可以毫不費力地為此制作一個封裝函數(shù)。

第一步是確定希望如何規(guī)范化錯誤。下面是一種方法：

export class NormalizedError extends Error {
  stack: string = ''
  /** The original value that was thrown. */
  originalValue: unknown
  /**
   * Initializes a new instance of the `NormalizedError` class.
   *
   * @param error - An `Error` object.
   * @param originalValue - The original value that was thrown.
   */
  constructor(error: Error, originalValue?: unknown) {
    super(error.message)
    this.stack = error.stack ?? this.message
    this.originalValue = originalValue ?? error
    Object.setPrototypeOf(this, NormalizedError.prototype)
  }
}

擴展 Error 對象的主要優(yōu)點是它的行為與標準錯誤類似。從頭開始創(chuàng)建一個自定義錯誤對象可能會導(dǎo)致復(fù)雜問題，尤其是在使用 instanceof 操作符檢查其類型時。這就是為什么要顯式地設(shè)置原型，以確保 instanceof 能正確工作，尤其是當代碼被移植到 ES5 時。

此外，Error 的所有原型函數(shù)在 NormalizedError 對象上都可用。構(gòu)造函數(shù)的設(shè)計還簡化了創(chuàng)建新 NormalizedError 對象的過程，因為它要求第一個參數(shù)必須是一個實際的 Error。以下是 NormalizedError 的優(yōu)點：

由于構(gòu)造函數(shù)要求第一個參數(shù)必須是 Error，因此它始終是一個有效的錯誤。
添加了一個新屬性 originalValue。這可以檢索拋出的原始值，這對于從錯誤中提取附加信息或在調(diào)試過程中非常有用。
堆棧永遠不會是未定義的。在許多情況下，記錄堆棧屬性比記錄消息屬性更有用，因為它包含更多信息。然而，TypeScript 將其類型定義為 string | undefined，這主要是出于跨環(huán)境兼容性的考慮（在傳統(tǒng)環(huán)境中經(jīng)常出現(xiàn)）。通過重寫類型并保證其始終為字符串，可以簡化其使用。

既然已經(jīng)定義了標準化錯誤的表示方法，就需要一個函數(shù)將 unknow 的拋出值轉(zhuǎn)換為標準化錯誤：

export const toNormalizedError = <E>(
  value: E extends NormalizedError ? never : E
): NormalizedError => {
  if (isError(value)) {
    return new NormalizedError(value)
  } else {
    try {
      return new NormalizedError(
        new Error(
          `Unexpected value thrown: ${
            typeof value === 'object' ? JSON.stringify(value) : String(value)
          }`
        ),
        value
      )
    } catch {
      return new NormalizedError(
        new Error(`Unexpected value thrown: non-stringifiable object`),
        value
      )
    }
  }
}

使用這種方法，不再需要處理 unknow 類型的錯誤。所有錯誤都將是合適的 Error 對象，從而為我們提供盡可能多的信息，并消除出現(xiàn)意外錯誤值的風(fēng)險。

為了安全地使用 NormalizedError 對象，我們還需要一個類型保護函數(shù)：

export const isNormalizedError = (value: unknown): value is NormalizedError =>
  isError(value) && 'originalValue' in value && value.stack !== undefined

現(xiàn)在，我們需要設(shè)計一個函數(shù)，幫助我們避免使用 try/catch 。另一個需要考慮的關(guān)鍵問題是錯誤的發(fā)生，它可以是同步的，也可以是異步的。理想情況下，我們需要一個能同時處理這兩種情況的函數(shù)。首先，讓我們創(chuàng)建一個類型保護來識別 Promise：

export const isPromise = (result: unknown): result is Promise<unknown> =>
  !!result &&
  typeof result === 'object' &&
  'then' in result &&
  typeof result.then === 'function' &&
  'catch' in result &&
  typeof result.catch === 'function'

有了安全識別 Promise 的能力，就可以繼續(xù)實現(xiàn)新的 noThrow 函數(shù)了：

type NoThrowResult<A> = A extends Promise<infer U>
  ? Promise<U | NormalizedError>
  : A | NormalizedError
export const noThrow = <A>(action: () => A): NoThrowResult<A> => {
  try {
    const result = action()
    if (isPromise(result)) {
      return result.catch(toNormalizedError) as NoThrowResult<A>
    }
    return result as NoThrowResult<A>
  } catch (error) {
    return toNormalizedError(error) as NoThrowResult<A>
  }
}

通過利用 TypeScript 的功能，我們可以動態(tài)支持異步和同步函數(shù)調(diào)用，同時保持準確的類型。這樣，我們就可以使用單個實用程序函數(shù)來管理所有錯誤。

此外，如前所述，這對解決范圍問題特別有用?？梢院唵蔚厥褂?noThrow，而不用將 try/catch 封裝在自己的匿名自調(diào)用函數(shù)中，這樣代碼的可讀性就大大提高了。

下面是一個重構(gòu)版本：

export const doStuffV3 = async (): Promise<void> => {
  const fetchDataResponse = await fetch('https://api.example.com/fetchData').catch(toNormalizedError)
  if (isNormalizedError(fetchDataResponse)) {
    return console.log('Error fetching data:', fetchDataResponse.stack)
  }
  const fetchDataText = await fetchDataResponse.text()
  if (!fetchDataResponse.ok) {
    return console.log(
      `Unexpected response while fetching data. Status: ${fetchDataResponse.status} | Status text: ${fetchDataResponse.statusText} | Body: ${fetchDataText}`
    )
  }
  const fetchData = noThrow(() => JSON.parse(fetchDataText) as unknown)
  if (isNormalizedError(fetchData)) {
    return console.log(
      `Failed to parse fetched data response as JSON: ${fetchDataText}`,
      fetchData.stack
    )
  }
  if (
    !fetchData ||
    typeof fetchData !== 'object' ||
    !('data' in fetchData) ||
    !fetchData.data
  ) {
    return console.log(
      `Fetched data is not in the expected format. Body: ${fetchDataText}`,
      toNormalizedError(new Error('Invalid data format')).stack
    )
  }
  const storeDataResponse = await fetch('https://api.example.com/storeData', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(fetchData),
    }).catch(toNormalizedError)
  if (isNormalizedError(storeDataResponse)) {
    return console.log('Error storing data:', storeDataResponse.stack)
  }
  const storeDataText = await storeDataResponse.text()
  if (!storeDataResponse.ok) {
    return console.log(
      `Unexpected response while storing data. Status: ${storeDataResponse.status} | Status text: ${storeDataResponse.statusText} | Body: ${storeDataText}`
    )
  }
}

這樣就解決了所有的疑難雜癥：

類型現(xiàn)在可以安全使用，因此不再需要 logError，可以直接使用 console.log 來記錄錯誤。
使用 noThrow 可以控制范圍，在定義 const fetchData 時就證明了這一點，以前必須使用 let fetchData。
嵌套已減少到單層，使代碼更易于維護。

你可能還注意到，我們在 fetch 時沒有使用 noThrow。相反，使用了 toNormalizedError，其效果與 noThrow 差不多，但嵌套更少。由于我們構(gòu)建 noThrow 函數(shù)的方式，你可以在獲取時使用它，就像我們在同步函數(shù)中使用它一樣：

const fetchDataResponse = await noThrow(() =>
    fetch('https://api.example.com/fetchData')
  )

總結(jié)

在不斷變化的軟件開發(fā)環(huán)境中，錯誤處理仍然是穩(wěn)健應(yīng)用程序設(shè)計的基石。正如我們在本文中所探討的，try/catch 等傳統(tǒng)方法雖然有效，但有時會導(dǎo)致代碼結(jié)構(gòu)復(fù)雜，尤其是在結(jié)合 JavaScript 和 TypeScript 的動態(tài)特性時。通過使用 TypeScript 的功能，展示了一種精簡的錯誤處理方法，它不僅簡化了我們的代碼，還增強了代碼的可讀性和可維護性。

NormalizedError 類和 noThrow 實用功能的引入展示了現(xiàn)代編程范式的強大功能。這些工具允許開發(fā)人員從容地處理同步和異步錯誤，確保應(yīng)用程序在面對突發(fā)問題時仍能保持彈性。

以上就是關(guān)于在Typescript中做錯誤處理的方案詳解的詳細內(nèi)容，更多關(guān)于Typescript錯誤處理的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: