我的代码中似乎到处都有begin ... rescue ... end 语句！这似乎不是正确的做法。
谁能建议我如何在不必将所有内容都放入begin ... rescue ... end 的情况下捕获任何异常？有什么方法可以告诉 Ruby 闭嘴，即使引发异常也继续运行？
【问题讨论】：
标签： ruby exception exception-handling
与其他语言一样，对于任何重要的程序，您实际上都需要一个经过深思熟虑的架构来处理异常。一种方法是在项目中定义异常处理范围，然后您通常希望在范围边界处捕获（救援）异常。有一个权衡。您在堆栈中越靠近发生异常的位置，您拥有的有关触发它的条件的上下文信息就越多。如果您尝试过于细化，则会遇到您所描述的问题。另一方面，如果您只在堆栈顶部（在“main”中）捕获异常，则没有上下文。因此，定义异常处理范围涉及评估与您的特定程序或系统相关的权衡。
Ruby 让我们能够“重试”——在其他一些语言中不可用。这应该谨慎使用！但在有意义的地方（例如等待网络或资源被释放），此类异常需要在本地处理。
否则，我倾向于在大型项目中以相当粗粒度的级别定义异常范围。当异常从起源点通过各种异常范围边界冒泡时，捕获一些上下文信息通常很有用。为了解决这个问题，您可以通过定义一些您自己的特定于应用程序的异常类型来扩展 Ruby 异常类层次结构，但同样需要权衡取舍。您的项目应该有明确的标准，关于何时使用自定义异常类型与在消息字段中捕获上下文数据、消息字段应该包含什么样的信息等，以及对代码可以生成的消息进行分类的策略。
在大多数情况下，可以允许异常向上传播到集中式处理程序，进行记录（用于技术团队和支持），为用户生成有用的错误消息，并确定情况是否严重到足以要求您的程序退出。通常，所有异常都应在您的代码或您正在使用的应用程序框架内处理。不应允许任何异常逃逸到语言运行时或操作系统的默认异常处理。
这些是我的想法，主要基于使用其他语言的经验，但我认为它们相当普遍。归根结底，在大型项目中，您需要投入大量精力来设计异常处理，而不是临时方法。
【讨论】：
def action
yield
rescue
....
ensure
....
end
action { stuff_goes_here }
【讨论】：
可以使它看起来更简洁的一件事是将救援放在方法的末尾，这样您就不需要开始和另一个级别的缩进：
def get_file_prompt
print "Enter file name: "
return File.open(read)
rescue StandardError
puts "File could not be opened"
return nil
end
【讨论】：
嗯，不。异常的全部意义在于它们是必须处理的条件。
这样想：例外是你的朋友！没有它们，你将不得不编写大量枯燥的条件语句，难以阅读和维护。
如果您正在学习 Ruby（或任何具有异常系统的语言），处理异常是最重要的方面之一，您最好花时间弄清楚如何处理它们，何时重新提出它们，以及何时可以安全地忽略它们。
【讨论】：