2010-04-17 76 views
4

看来我在我的代码中随处可见begin ... rescue ... end声明!这似乎不是正确的做法。在Ruby中替代救援?

任何人都可以建议如何我可以捕捉任何异常,而无需将所有内容放入begin ... rescue ... end?任何方式只是告诉Ruby闭嘴,即使引发异常也继续前进?

+0

如果引发异常,通常是因为发生了Ruby *无法自动继续的情况。如果你可以设计一个适合你的问题的代码片段,那么这就是拯救部分 – Gareth 2010-04-17 05:32:06

+0

的一个重点,它可以让我们判断你是否有异常需求。 – 2010-04-17 05:46:02

回答

10

与其他语言一样,对于任何非平凡的程序,实际上您都需要经过深思熟虑的架构来处理异常。一种方法是在您的项目中定义异常处理范围,然后通常希望在范围边界处捕获(挽救)异常。有一个权衡。越接近堆栈,发生异常的位置越多,关于触发它的条件的上下文信息也越多。如果你试图过于细化,你会遇到你所描述的问题。另一方面,如果你只在栈顶捕获异常(在“main”中),那么就没有上下文。因此,定义异常处理范围涉及评估与您的特定程序或系统有关的权衡。

Ruby使我们能够“重试” - 在某些其他语言中不可用。这应该谨慎使用!但是在有意义的地方(例如等待网络或资源被释放),这些异常需要在本地处理。

否则,我倾向于在大型项目中对相当粗粒度级别的异常作用域进行定义。捕获一些上下文信息通常是有用的,因为从起始点到各种异常范围边界异常冒泡。为了解决这个问题,您可以通过定义一些您自己的特定于应用程序的异常类型来扩展Ruby异常类层次结构,但同样存在权衡。您的项目应具有关于何时使用自定义异常类型与捕获消息字段中的上下文数据,消息字段应该包含什么类型的信息等的明确标准,以及用于对代码可生成的消息进行编目的策略。

在大多数情况下,可以允许异常向上传播到中央处理程序,记录(针对技术团队和支持),为用户生成有用的错误消息,并确定条件是否足够严重要求您的程序退出。通常,所有的异常都应该在您的代码中或在您使用的应用程序框架内处理。不应该允许任何异常转移到语言运行时或操作系统的缺省异常处理。

这些是我的想法,主要基于其他语言的经验,但我认为他们适用于相当普遍。总之,在一个大型项目中,您需要付出相当大的努力来设计异常处理,而不是专门的方法。

4

有一两件事可以使它看上去有点吸尘器把救援在方法的结束,所以你并不需要一个开始和缩进的另一个层面:

def get_file_prompt 
    print "Enter file name: " 
    return File.open(read) 
rescue StandardError 
    puts "File could not be opened" 
    return nil 
end 
1

哦,不。例外的要点是它们是必须处理的条件。

想想这样:例外是你的朋友!没有他们,你将不得不写很多无聊的条件陈述,这些陈述很难阅读和维护。

如果您正在学习Ruby(或任何带有异常系统的语言),处理异常是最重要的方面之一,您应该花时间弄清楚如何处理它们,何时重新处理 - 提醒他们,以及何时可以忽略他们。

6
def action 
    yield 
    rescue 
     .... 
    ensure 
     .... 
end 

action { stuff_goes_here }