javascript - 抛出与从服务类返回错误

Question

从服务类抛出错误与返回错误之间有实质性区别吗？

class ProductService {
    async getProduct(id) {
        const product = await db.query(`...`)

        if (!product) {
            throw new ProductNotFoundError()
        }

        return product
    }

    // VS
    
    async getProduct(id) {
        const product = await db.query(`...`)

        if (!product) {
            return {
                data: null,
                error: new ProductNotFoundError()
            }
        }

        return {
            error: null,
            data: product
        }
    }
}

在此示例中，如果未找到产品，我想发出错误消息(据说返回 null 是不够的，也许我还需要提供其他信息，说明为什么找不到产品)。

作为一般设计原则，是否有首选方法，这两种方法是否有任何实质性的优点/缺点？

我一直在做throw new Error 示例，但是代码中充满了 try/catch 或 .then/.catch 语句，这使得推理变得有些困难。

我特别不喜欢抛出错误的是……它们并不意外。显然，我预计可能找不到产品，因此我添加了一段逻辑来处理该部分。然而，它最终被调用者以相同的方式接收，例如，接收到 TypeError。一种是预期的域错误，另一种是意外的异常。

在第一种情况下，如果我返回一个带有 data 和 error 属性的对象(或者我可以返回一个带有 isError 等方法的对象, isSuccess 和 getData 来自每个服务，这是相似的)，我至少可以相信我的代码不会引发异常。如果一个碰巧出现，那么它将被定义为意外并被全局错误处理程序(例如 express 中间件)捕获。

Answer 1

Is there a substantial difference between throwing vs returning an error from a service class?

差别很大。异步函数中的 throw 会导致从任何 async 函数返回的 promise 被拒绝，并将该异常作为拒绝原因。返回值成为 promise 的 resolved 值。

因此，最大的区别在于从 async 函数返回的 promise 是使用值解决还是使用原因拒绝。

As a general design principle, is there a preferred approach, are there any substantial pros/cons of both approaches?

大多数人在异常情况下使用 promise 拒绝，在这种情况下，调用者通常希望停止他们的正常代码流并寻求不同的代码路径，并对可能继续正常代码流的内容使用返回值。想想链式 promise :

x().then(...).then(...).catch(...)

如果条件应该立即转到 .catch() 因为一些严重的事情被破坏了，那么在 x() 中抛出/拒绝最有意义。但是，如果条件只是通常要处理并继续正常执行的东西，那么您可能只想返回一个值而不是抛出/拒绝。

因此，您尝试将 x() 设计为最容易实现预期用途。在数据库中找不到产品是一种预期的可能情况，但它也可能是调用者想要中止他们所在的逻辑流的事情，但对该情况的处理肯定不同于实际错误数据库。

作为引用示例，您会注意到大多数数据库不会将未能在查询中找到某些内容视为错误。这只是“未找到”的结果。