在Ruby中拯救的替代方法? [英] Alternative to rescue in Ruby?

问题描述

似乎我的代码中到处都有 begin ...抢救... end 语句！这似乎不正确.

It seems like I have begin ... rescue ... end statements everywhere in my code! This doesn't seem like the correct thing to do.

有人可以建议我如何捕获任何异常，而不必将所有内容都放置在 begin ...救援... end 内吗?有什么方法可以告诉Ruby关闭并继续运行，即使引发了异常?

Can anyone suggest how I can catch any exceptions without having to place everything inside begin ... rescue ... end? Any way to just tell Ruby to shut up and just keep going even if an exception is raised?

推荐答案

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

As in other languages, for any non-trivial program, you actually need a well-thought-out architecture for processing exceptions. One approach is to define exception-handling scopes within your project, and then you typically want to catch (rescue) exceptions at the scope boundaries. There is a trade-off. The closer you are in the stack to where the exception occurred, the more contextual information you have about the condition that triggered it. If you try to be too granular, you run into the problems that you have described. On the other hand, if you only catch exceptions at the top of the stack (in "main"), then there is no context. So defining the exception-handling scopes involves evaluating that tradeoff in relation to your particular program or system.

Ruby使我们能够重试"-其他某些语言不提供.应该谨慎使用！但是在有意义的地方(例如，等待网络或资源被释放)，此类异常需要在本地进行处理.

Ruby gives us the ability to "retry" -- not available in some other languages. This should be used sparingly! But where it makes sense (e.g. waiting for the network or a resource to be freed), such exceptions need to be handled very locally.

否则，我倾向于在大型项目中以相当粗略的级别定义异常作用域.捕获一些上下文信息通常很有用，因为异常会从始发点通过各种异常作用域边界冒出.为了解决这个问题，您可以通过定义一些自己的特定于应用程序的异常类型来扩展Ruby异常类的层次结构，但还是要权衡取舍.您的项目应具有明确的标准，有关何时使用自定义异常类型与在消息字段中捕获上下文数据，消息字段应包含哪些信息等有关的信息，以及对代码可生成的消息进行分类的策略.

Otherwise, I tend to define exception scopes at a fairly coarse-grained level on a large project. It is often useful to capture some contextual information as the exception bubbles up from the point of origination through the various exception scope boundaries. To help with this, you can extend the Ruby exception class hierarchy by defining some of your own application-specific exception types, but again there are trade-offs. Your project should have clear standards about when to use custom exception types vs. capturing contextual data in the message field, what kind of information the message field should contain, etc., and a strategy for cataloguing the messages that your code can generate.

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

In most cases, exceptions can be allowed to propagate upward to a centralized handler, to be logged (for the technical team and support), to generate useful error messages for the user, and to determine whether the condition is serious enough to require your program to exit. Generally, all exceptions should be handled within your code or within the application framework you are using. No exceptions should be allowed to escape to the default exception handling of the language runtime or the OS.

我的这些想法主要基于其他语言的经验，但我认为它们普遍适用.最重要的是，在大型项目中，与临时方法相比，您需要付出更多的精力来设计异常处理.

Those are my thoughts based mostly on experience with other languages, but I think they apply pretty generally. Bottom line, on a large project you need to put quite a lot of effort into designing exception handling, vs. an ad hoc approach.

这篇关于在Ruby中拯救的替代方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！