关于在Typescript中做错误处理的方式详解

更新时间：2023年09月07日 09:09:16 作者：托儿所夜十三

错误处理是软件工程重要的一部分,如果处理得当,它可以为你节省数小时的调试和故障排除时间,我发现了与错误处理相关的三大疑难杂症：TypeScript的错误类型,变量范围和嵌套,让我们逐一深入了解它们带来的挠头问题,感兴趣的朋友可以参考下

疑难杂症一：Typescript 错误类型

在 JavaScript 中最常见的错误处理方式与大多数编程语言相同：

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 的人来说遇到这种问题是非常挠头的。解决这一问题的常用方法是简单地将错误转为其他类型，如下所示：

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)
}

执行这段代码将导致在 "catch "代码块中抛出新的错误，这就没有达到使用 try/catch 的目的：

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

问题产生的原因是 undefined 中不存在 message 属性，从而导致在 catch 代码块中出现 TypeError。在 JavaScript 中，只有两个值会导致这个问题：undefined 和 null。

现在可能有人会问，有人抛出 undefined 或 null 的可能性有多大。虽然这种情况可能很少发生，但如果真的发生了，就会在代码中引入意想不到的行为。此外，考虑到在 TypeScript 项目中通常会使用大量第三方包，如果其中一个包无意中抛出了一个不正确的值，也不足为奇。

这就是 TypeScript 将可抛类型设置为 unknow 的唯一原因吗？乍一看，这可能只是一个罕见的边缘情况，使用类型转换是一个比较靠谱的解决方式。然而，事情并非如此简单。虽然 undefined 和 null 是最具破坏性的情况，因为它们可能导致应用程序崩溃，但其他值也可能被抛出。例如：

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

这里的主要区别在于，它不会抛出 TypeError，而是直接返回 undefined。虽然这不会直接导致应用程序崩溃，因此破坏性较小，但也会带来其他问题，例如在日志中显示未定义。此外，根据使用undefined 值的方式，它还可能间接导致应用程序崩溃。请看下面的示例：

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

在这里，调用 undefined 上的 .trim() 将触发 TypeError，可能导致应用程序崩溃。

从本质上讲，TypeScript 的目的是通过将 catchables 的类型指定为 unknow 来保护我们。这种方法让开发人员有责任确定抛出值的正确类型，有助于防止出现运行时问题。

如下所示，您可以使用可选的链式操作符 (?.) 来保护您的代码：

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

虽然这种方法可以保护你的代码，但它使用了两个会使代码维护复杂化的 TypeScript 特性：

类型转换破坏了 TypeScript 的保障措施，即确保变量遵循其指定的类型。
在非可选类型上使用可选的链式操作符，在类型不匹配的情况下，如果有人遗漏了这些操作符，也不会引发任何错误。

更好的方法是利用 TypeScript 的类型保护。类型保护本质上是一种函数，它能确保特定值与给定类型相匹配，并确认可以安全地按预期使用。下面是一个类型保护的示例，用于验证捕获的变量是否属于 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。然后，它会检查它是否是一个具有预期属性的对象。

这种类型保护可以在代码的任何地方重复使用，以验证对象是否是 Error。下面是一个应用示例：

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)
}

通过创建一个利用 isError 类型防护的 logError 函数，我们可以安全地记录标准错误以及任何其他抛出的值。这对于排除意外问题特别有用。不过，我们需要谨慎，因为 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 代码块内定义的，因此在该代码块外无法访问。为了解决这个问题，你可能会想在 try 代码块之外定义变量：

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

这种方法并不理想。使用 let 而不是 const，就意味着变量是可变的，这会带来潜在的错误。此外，它还会增加代码的阅读难度。

规避这一问题的方法之一是将 try/catch 代码块封装在一个函数中：

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

虽然这种方法解决了可变性问题，但却使代码变得更加复杂。我们可以通过创建自己的可重用封装函数来解决这个问题。

疑难杂症三：嵌套

下面的示例演示了如何在可能出现多个错误的情况下使用新的 logError 函数：

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)
  }
}

你会发现调用的是 .text() API，而不是 .json()。因为 fetch 能调用这两种方法中的一种。由于我们的目标是在 JSON 转换失败时显示正文内容，因此首先调用 .text()，然后手动还原为 JSON，确保在此过程中捕捉到任何错误。为避免出现以下隐含错误：

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

虽然错误提供的细节会使代码更容易调试，但其有限的可读性会给代码维护带来挑战。try/catch 块引起的嵌套增加了阅读函数时的认知负担。不过，有一种方法可以简化代码，如下所示：

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)
  }
}

这次重构解决了嵌套问题，但也带来了一个新问题：错误报告的粒度不够。通过删除检查，变得更加依赖错误信息本身来理解问题。正如我们从一些 JSON.parse 错误中看到的那样，这并不总能提供最好的颗粒度。

考虑到我们讨论的所有的疑难杂症，是否存在有效处理错误的最佳方法？

解决方案

应该寻求一种比传统的 try/catch 块更优越的错误处理方法。通过利用 TypeScript 的功能，我们可以毫不费力地为此制作一个封装函数。

第一步是确定希望如何规范化错误。下面是一种方法：

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 对象的主要优点是它的行为与标准错误类似。从头开始创建一个自定义错误对象可能会导致复杂问题，尤其是在使用 instanceof 操作符检查其类型时。这就是为什么要显式地设置原型，以确保 instanceof 能正确工作，尤其是当代码被移植到 ES5 时。

此外，Error 的所有原型函数在 NormalizedError 对象上都可用。构造函数的设计还简化了创建新 NormalizedError 对象的过程，因为它要求第一个参数必须是一个实际的 Error。以下是 NormalizedError 的优点：

由于构造函数要求第一个参数必须是 Error，因此它始终是一个有效的错误。
添加了一个新属性 originalValue。这可以检索抛出的原始值，这对于从错误中提取附加信息或在调试过程中非常有用。
堆栈永远不会是未定义的。在许多情况下，记录堆栈属性比记录消息属性更有用，因为它包含更多信息。然而，TypeScript 将其类型定义为 string | undefined，这主要是出于跨环境兼容性的考虑（在传统环境中经常出现）。通过重写类型并保证其始终为字符串，可以简化其使用。

既然已经定义了标准化错误的表示方法，就需要一个函数将 unknow 的抛出值转换为标准化错误：

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 对象，从而为我们提供尽可能多的信息，并消除出现意外错误值的风险。

为了安全地使用 NormalizedError 对象，我们还需要一个类型保护函数：

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

现在，我们需要设计一个函数，帮助我们避免使用 try/catch 。另一个需要考虑的关键问题是错误的发生，它可以是同步的，也可以是异步的。理想情况下，我们需要一个能同时处理这两种情况的函数。首先，让我们创建一个类型保护来识别 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 的能力，就可以继续实现新的 noThrow 函数了：

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 的功能，我们可以动态支持异步和同步函数调用，同时保持准确的类型。这样，我们就可以使用单个实用程序函数来管理所有错误。

此外，如前所述，这对解决范围问题特别有用。可以简单地使用 noThrow，而不用将 try/catch 封装在自己的匿名自调用函数中，这样代码的可读性就大大提高了。

下面是一个重构版本：

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}`
    )
  }
}

这样就解决了所有的疑难杂症：

类型现在可以安全使用，因此不再需要 logError，可以直接使用 console.log 来记录错误。
使用 noThrow 可以控制范围，在定义 const fetchData 时就证明了这一点，以前必须使用 let fetchData。
嵌套已减少到单层，使代码更易于维护。

你可能还注意到，我们在 fetch 时没有使用 noThrow。相反，使用了 toNormalizedError，其效果与 noThrow 差不多，但嵌套更少。由于我们构建 noThrow 函数的方式，你可以在获取时使用它，就像我们在同步函数中使用它一样：

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

总结

在不断变化的软件开发环境中，错误处理仍然是稳健应用程序设计的基石。正如我们在本文中所探讨的，try/catch 等传统方法虽然有效，但有时会导致代码结构复杂，尤其是在结合 JavaScript 和 TypeScript 的动态特性时。通过使用 TypeScript 的功能，展示了一种精简的错误处理方法，它不仅简化了我们的代码，还增强了代码的可读性和可维护性。

NormalizedError 类和 noThrow 实用功能的引入展示了现代编程范式的强大功能。这些工具允许开发人员从容地处理同步和异步错误，确保应用程序在面对突发问题时仍能保持弹性。

以上就是关于在Typescript中做错误处理的方案详解的详细内容，更多关于Typescript错误处理的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

javascript中parentNode,childNodes,children的应用详解
本篇文章是对javascript中parentNode,childNodes,children的应用进行了介绍，需要的朋友可以过来参考下，希望对大家有所帮助
2013-12-12
javascript四舍五入函数代码分享(保留后几位)
这篇文章主要介绍了javascript四舍五入函数分享，大家参考使用吧
2013-12-12
JavaScript自定义Webpack配置实现流程介绍
本系列主要整理前端面试中需要掌握的知识点。本节介绍webpack如何优化前端性能，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
2022-10-10
js的onload事件及初始化按钮事件示例代码
onload事件当一个页面或是一张图片加载完成时被触发，在body上不仅可以用onload，而且还支持多个HTML标签.用法如下
2013-09-09
js和css写一个可以自动隐藏的悬浮框
用js和css写一个可以自动隐藏的悬浮框。css肯定是用来控制样式的，js用来控制器显示与隐藏的,需要的朋友可以参考下
2014-03-03
关于Javascript 对象(object)的prototype
Javascript中的每个对象(object)都会有 prototype，下面为大家介绍下其具体的应用
2014-05-05
JS、CSS以及img对DOMContentLoaded事件的影响
最近在做性能有关的数据上报，发现了两个非常有意思的东西：Chrome开发者工具的Timeline分析面板，以及DOMContentLoaded事件。一个是强大的令人发指的性能分析工具，一个是重要的性能指标，于是就用Timeline对DOMContentLoaded事件进行了一番研究
2014-08-08
JavaScript创建一个object对象并操作对象属性的用法
这篇文章主要介绍了JavaScript创建一个object对象并操作对象属性的用法,实例分析了javascript使用object类定义对象及属性的用法,需要的朋友可以参考下
2015-03-03
阻止JavaScript事件冒泡传递（cancelBubble 、stopPropagation）
阻止JavaScript事件冒泡传递（cancelBubble 、stopPropagation）...
2007-05-05
详解ES6 Promise的生命周期和创建
这篇文章主要介绍了详解ES6 Promise Promise的生命周期和创建,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
2019-08-08