【问题标题】:Using recursion in try catch block in JavaScript在 JavaScript 的 try catch 块中使用递归
【发布时间】:2021-09-06 10:08:18
【问题描述】:

我有一个 nodejs 脚本,它为当天记录的温度创建动态表和视图。如果温度不在正常范围内,有时它不会创建表。为此,我决定使用 try catch 并递归调用该函数。我不确定我是否做得正确,或者是否有另一种方法可以调用 con.query 方法,以便创建表。第一次在nodejs中遇到这个问题。

【问题讨论】:

  • 这甚至无法正常运行,因为resolve() 将在您尝试调用它的范围内未定义。请发布您实际尝试运行的代码。如果它确实运行了,它只会运行一个无限循环,因为你没有错误检测或完成检测会停止循环。
  • 是的,它确实提供了一个无限循环,我是新手,所以在使用递归方面没有进展。你能帮我解决这个问题吗?
  • 好吧,首先,您应该只在遇到特定错误时再次调用该函数。如果你得到一个可接受的结果,你不应该继续递归。这就是使它成为无限循环的原因。您应该检测特定条件,并且只有在这些条件发生时才会递归。
  • 那么如何处理呢?
  • 有时它不会创建表,所以我将如何检测到

标签: javascript mysql node.js recursion try-catch


【解决方案1】:

首先,您必须检测错误并且仅在存在特定错误条件时进行递归。如果您要解决的问题是一个特定错误,那么您可能应该检测到该特定错误并仅在遇到该精确错误时重复该操作。

然后,一些其他的重试建议:

  1. 仅重试固定次数。当一些服务器代码卡在一个循环中,一遍又一遍地敲打某些东西并且每次都得到相同的错误时,这是​​系统操作员的噩梦。

  2. 仅在特定条件下重试。

  3. 记录每个错误,以便您作为运行服务器的人可以在出现问题时解决问题。

  4. 仅在延迟一段时间后重试。

  5. 如果您要重试多次,则实施退避延迟,以便重试之间的时间越来越长。

下面是一些代码实现重试的总体思路:

const maxRetries = 5;
const retryDelay = 500;

function execute_query(query, callback) {
    let retryCntr = 0;
    
    function run() {
        con.query(query, function(err, result, fields) {
             if (err && err is something we should retry for) {
                  ++retryCntr;
                  if (retryCntr <= maxRetries) {
                      console.log('Retrying after error: ', err);
                      setTimeout(run, retryDelay)
                  } else {
                      // too many retries, communicate back error
                      console.log(err);
                      callback(err);
                  }
             } else if (err) {
                  console.log(err);
                   // communicate back error
                   callback(err);
             } else {
                  // communicate back result
                  callback(null, result, fields);
             }
        });
    }

    run();
}

如果您要进行大量重试,重试和退避背后的想法是,重试算法会导致所谓的雪崩失败。系统变得有点慢或有点太忙,它开始产生一些错误。因此,您的代码开始一遍又一遍地重试,这会产生更多的负载,从而导致更多的错误,因此更多的代码开始重试,然后整个事情就会失败,大量代码循环和重试,这就是所谓的雪崩失败。

因此,相反,当出现错误时,您必须确保不会无意中使系统不堪重负,并可能使情况变得更糟。这就是你实现短延迟的原因,这就是你实现最大重试次数的原因,这就是为什么你甚至可以实现一个退避算法来使每次重试之间的延迟更长。所有这一切都允许出现某种错误导致扰动的系统最终自行恢复,而不仅仅是让问题变得更糟,以至于一切都失败了。

【讨论】:

  • 出现的错误是未处理的承诺拒绝警告:ER_SP_DOES_NOT_EXIST PROCEDURE create_live_tick_table 不存在
  • @ness - 这听起来不像是你需要重试的东西。听起来您只需要正确地对代码进行排序,以便在前一个数据库操作完成之前不会开始下一个数据库操作。您没有显示任何可以实际运行的代码,我们可以根据这些代码提供帮助。
  • 我添加了整个代码,请告诉我
  • @ness - 我不知道ER_SP_DOES_NOT_EXIST PROCEDURE 错误是什么意思。我猜你需要知道你的数据库的人的帮助。也许这意味着您的数据库中还没有存储过程create_live_tick_table()
猜你喜欢
  • 1970-01-01
  • 2011-07-12
  • 1970-01-01
  • 2015-01-07
  • 2019-12-04
  • 2010-10-31
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多