开始救援未捕获错误

发布于 2024-09-08 04:58:28 字数 1028 浏览 7 评论 0原文

我正在使用一些包含在 begin -rescue 块中的 ruby​​ 代码,但不知何故它仍然崩溃。

代码块如下所示:

# Retrieve messages from server
def get_messages
  @connection.select('INBOX')
  @connection.uid_search(['ALL']).each do |uid|
    msg = @connection.uid_fetch(uid,'RFC822').first.attr['RFC822']
    begin
      process_message(msg)
      add_to_processed_folder(uid) if @processed_folder
    rescue
       handle_bogus_message(msg)
    end
    # Mark message as deleted 
    @connection.uid_store(uid, "+FLAGS", [:Seen, :Deleted])
  end
end

鉴于此代码,我假设如果 process_messageadd_to_processed_folder 无法执行,则救援将启动并调用 handle_bogus_message >。话虽这么说,我在生产环境中运行此代码,有时当我“收到”电子邮件消息(这是从 rake 任务运行)时,它会因SyntaxError而终止。

要查看错误消息,请查看 http://pastie.org/1028479,而不是 process_message它所指的与上面的process_message相同。有什么原因导致 begin - rescue 不会捕获此异常?

I'm using some ruby code wrapped in a begin - rescue block but somehow it manages to still crash.

the block of code looks like this:

# Retrieve messages from server
def get_messages
  @connection.select('INBOX')
  @connection.uid_search(['ALL']).each do |uid|
    msg = @connection.uid_fetch(uid,'RFC822').first.attr['RFC822']
    begin
      process_message(msg)
      add_to_processed_folder(uid) if @processed_folder
    rescue
       handle_bogus_message(msg)
    end
    # Mark message as deleted 
    @connection.uid_store(uid, "+FLAGS", [:Seen, :Deleted])
  end
end

Given this code i would assume that if process_message or add_to_processed_folder could not execute then rescue would kick in and call handle_bogus_message. That being said I'm running this code in a production environment and sometimes when i "get" an email message (this is run from a rake task) it dies with a SyntaxError.

For a look at the error message check out http://pastie.org/1028479 and not that process_message that it is referring to is the same process_message above. Is there any reason why begin - rescue won't catch this exception?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

满意归宿 2024-09-15 04:58:35

不带任何参数的 rescue 接受 StandardError 类引发的异常。您的错误类型是 SyntaxError,它继承自另一个名为 ScriptError 的类。所有这些错误类都是 Exception 类的子类。因此,正如 sepp2k 建议的那样,使用 rescue Exception 来捕获各种异常。

rescue without any parameter accepts exceptions raised by StandardError class. Your error type is SyntaxError which is inherited from a different class called ScriptError. All these error classes are subclasses of Exception class. So as sepp2k suggested use rescue Exception to catch all kinds of exceptions.

べ繥欢鉨o。 2024-09-15 04:58:34

不带参数的 rescue 仅挽救从 StandardError 继承的异常。要挽救 SyntaxError,请使用 rescue SyntaxError

要拯救所有异常,您可以使用 rescue Exception,但请注意,这是一个坏主意(这就是为什么它不是 rescue 的默认行为),如 此处此处。尤其是这一部分:

救援中断可防止用户使用 CTRLC 退出程序。

拯救 SignalException 会阻止程序正确响应信号。除了用kill -9 之外,它是无法杀死的。

rescue without a parameter just rescues exceptions that inherit from StandardError. To rescue a SyntaxError use rescue SyntaxError.

To rescue all exceptions you would use rescue Exception, but note that that's a bad idea (which is why it's not the default behavior of rescue) as explained here and here. Especially this part:

Rescuing Interrupt prevents the user from using CTRLC to exit the program.

Rescuing SignalException prevents the program from responding correctly to signals. It will be unkillable except by kill -9.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文