try-catch 是否比 fail only if-else 更快？

Question

我的情况是我有一个小的 javascript 程序运行处理大量格式化为二维数组的数据。对于每个循环，它循环遍历数据，调用序列化程序方法在进行计算之前序列化该记录。每个周期的数据将是相同的。所以现在我想将序列化数据缓存到另一个数组中，这样从第二次开始就不必再次调用序列化程序了。

这是我的函数：

  var cached=[];
  function getRow(x,y){
    if(!cached[x]){
      cached[x] = [];
    }
    if(!cached[x][y]){
      cached[x][y] = serializer(data,x,y);
    }
    return cached[x][y] ;
  }

到目前为止它有效。但是正如您所看到的，对于每一行，它必须在 returning 缓存数据之前检查 2 个条件，并且该条件仅在第一个周期中有用。所以我正在考虑使用 try-catch 而不是 if-else 来处理它。这样在第一个周期中，try 块将一直失败，然后我将填充 catch 块中的缓存。然后在所有数据都被缓存的第一个周期之后，它会直接获取值并 return 它。

但我担心的是：这样做会更快还是 try-catch 会减慢功能和性能？

Answer 1

try/catch 只会在没有错误抛出的情况下更有效率。而且，让我们明确一点，对于现代客户端，效率的提高将是微不足道的，并且在大多数应用程序中可能不会引人注意。

当错误被抛出时，性能会受到影响，因为错误对象被实例化和配置，为该错误对象创建一个范围以存在于其中，并且（当然）JS 运行时必须从错误中恢复。

根据我的经验，try/catch 通常首先被错误地使用。用try/catch不应该是"choice"的事，应该是事或必然。如果您的代码有可能导致错误，并且有一种方法可以让您对其进行编码以避免该错误，请执行此操作 - - 不需要 try/catch。

示例：

应处理因用户输入错误而可能发生的错误通过重新思考 UI 以及输入的处理方式。
由于与远程交互不良而可能发生的错误 source (think AJAX) 通常有错误和超时回调选项。

如果您的代码有办法抛出错误并且它超出了您的代码的控制范围（网络中断、服务器错误），try/catch 可能有必要。我说可能因为现在很多 API 都有错误回调函数来处理这些事情。

总之，千万不要只选择try/catch。 try/catch 是在没有其他解决方案可用时使用的语言功能。

try-catch 是否比 fail only if-else 更快？

Is try-catch faster than fail only if-else?

javascript

performance-testing