为什么要救出一个例外然后再提出一个例

时间:2014-06-12 02:37:06

标签: ruby-on-rails ruby exception-handling

我正在查看mandrill文档中的ruby api调用https://mandrillapp.com/api/docs/users.ruby.html#method=ping,我注意到他们拯救了Mandrill::Error然后raise另一个例外。

我很好奇为什么有人会抓到一个例外然后再提出另一个例外。这对我没有意义。

begin
    mandrill = Mandrill::API.new 'YOUR_API_KEY'
    result = mandrill.users.ping 
        # {"PING"=>"PONG!"}

rescue Mandrill::Error => e
    # Mandrill errors are thrown as exceptions
    puts "A mandrill error occurred: #{e.class} - #{e.message}"
    # A mandrill error occurred: Mandrill::InvalidKeyError - Invalid API key    
    raise
end

2 个答案:

答案 0 :(得分:7)

rescue Mandrill::Error => e
    # Mandrill errors are thrown as exceptions
    puts "A mandrill error occurred: #{e.class} - #{e.message}"
    # A mandrill error occurred: Mandrill::InvalidKeyError - Invalid API key    
    raise
end

在这种情况下,同样的例外被“重新提出”。此rescue块的唯一原因是记录有关异常的特定信息。

当异常特别有意义时,

begin/rescue块通常以这种方式使用,因此作者希望打印/记录异常信息。当下一个rescue块没有打印任何异常信息而是静默处理它时,尤其如此。

答案 1 :(得分:0)

raise将抛出运行时异常而不是正常异常。

这样做的另一个原因可能是代码想要抛出运行时错误而不是正常错误。如果代码在控制器的上下文中,则可能相关。

但是,我认为主要原因将是马丁的测井记录。