为什么要抢救异常然后引发异常？答案

【问题标题】：Why rescue an exception and then raise one?为什么要抢救异常然后引发异常？
【发布时间】：2014-06-12 02:37:05
【问题描述】：

我正在查看 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

【问题讨论】：

添加额外的调试信息？
在这种情况下没有意义：所有记录的信息都在异常中。请注意，same 异常被重新抛出，而不是新异常。
如果您需要在举手并说“我不知道如何处理这个问题”之前释放资源，重新抛出通常很有用。但是，在这种情况下，仅仅显示一个错误，其中包含某人可能从即将发生的堆栈跟踪中推断出的信息似乎有点没用。

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

【解决方案1】：

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 块没有打印任何异常信息而是静默处理时尤其如此。

【讨论】：

【解决方案2】：

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

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

但是，我认为主要原因将是 Martin 的日志记录答案。

【讨论】：

raise 将抛出最后一个异常。 IOW：它抛出刚刚捕获的完全相同异常。你的解释没有道理。