在设计Javascript API时，我应该使用控制台消息引发TypeError还是忽略？

我必须制作一个Javascript API，它是一个基于C的API的公共接口，该API具有枚举和必需的参数。Javascript是一种松散类型的语言，它不会提供使用基于C的API时可能得到的编译器警告

我的问题是，在围绕C API制作Javascript包装时，在Javascript文化中，是希望在传递无效数据时收到TypeError，还是希望API向控制台输出消息并忽略错误

下面是一些API的示例代码

var Foo = (function() {
  var foo = {

    Enum: {
      First: {value: 0},
      Second: {value: 1},
      Third: {value: 2}
    },

    bar: function(eenoom, aNumber) {
      if (!eenoom) {
        throw new TypeError("bar: You must specify the 'eenoom' parameter");
        return;
      }

      if (!aNumber || typeof aNumber != 'number') {
        throw new TypeError("bar: You must specify the 'aNumber' parameter (as a number)");
        return;
      }

      for (var key in foo.Enum) {
        if (foo.Enum.hasOwnProperty(key)) {
          if (foo.Enum[key] === eenoom) {
            console.log("You did it!");
            return;
          }
        }
      }
      throw new TypeError("bar: You must use the Foo.Enum enumeration");
    }
  }

  // So no one can mess with our enums
  Object.freeze(foo.Enum);

  return foo;
})();

Foo.bar(Foo.Enum.First, 20);
Foo.bar({value: 0}, 20); // Throws a TypeError

---

注意TypeError的用法。这是Javascript API的预期行为方式吗？

我主要做以下工作：

• 在同步公共API中，我总是检查参数并抛出相应的错误。不仅

  TypeError

  ，还包括其他适当的错误
• 通常情况下，我会在特殊情况下抛出错误-即，不符合深思熟虑的执行流程
• 在异步API中，我通过错误回调/拒绝函数报告错误

我认为

console.log（…）

继续下去不是个好主意。如果调用未满足API的先决条件，则API契约从一开始就被破坏。（除非合同是，特别是“是的，我能处理不良输入”，这是相当颓废的。）

在这种情况下，您以后所做的任何操作都是不正确的。因此，抛出一个错误并中断

---

作为一个API消费者，我会感谢抛出的错误，以及良好的堆栈跟踪和有意义的错误消息——比控制台中的一条有意义的完整错误消息（我可能注意到，也可能没有注意到）要多得多。

如果程序员编写了永远无法工作的代码（没有提供所需的参数，发送了错误的类型或参数顺序等…），然后您希望代码立即失败，明显失败，清楚地告诉程序员什么是错误的，并提供一个堆栈跟踪，精确显示出错代码的位置

在Javascript中，最干净的方法是抛出一个带有有意义描述的适当类型的错误。第一次执行此代码时，它将失败，开发人员将立即知道他们做错了什么。这就是您想要的。任何其他方法都会增加开发人员不立即执行的可能性意识到他们所犯的编程错误，或者即使他们意识到某些东西不起作用，他们也可能需要更长的时间来找出它不起作用的原因

console.log（）

语句有以下缺点：

它可能不会立即或根本看不见

它不提供堆栈跟踪，因此可能不清楚调用方代码的哪个特定部分导致了错误

由于应用程序可能不会出现明显的故障，因此当实际存在必须修复的重大编程错误时，可能看起来没有任何错误或严重错误

---

通常，如果您检测到编程错误（例如，编写了错误的代码），然后您应该抛出一个错误，以强制程序员在代码运行时立即查看并修复错误。您希望绝对确保立即看到此错误，因为代码永远无法工作。这与某些数据的意外情况不同，这些数据可能只是运行时条件（例如空数组）这是一个基于意见的问题，因此对你来说不是一个好问题SO@Jamiec-这个问题有很多可能的答案，这些答案都有充分的逻辑支持，而不仅仅是观点。@jfriend00-事实上有很多可能的答案可以证明我的观点。@Jamiec-不，没有。有这里有成百上千的问题，它们得到的答案不尽相同，也不只是基于观点。一个问题不一定只有一个可能的答案才能不基于观点。天哪。