在Rails中处理奇怪异常的最佳做法是什么？

让我们说，我在Rails的这个功能（其实我也：P - EVAL被使用，因为会出现第三，第四或更多class_number在未来）：在Rails中处理奇怪异常的最佳做法是什么？

def all_profession_costs(class_number) 
     second = {'Wealth Ranger' => 1000, 'Wisdom Vacuum' => 1000, 'Life Leecher' => 1000, 'Dense Mass' => 1000} 
     costs = eval(class_number) 
     costs 
    end

这似乎是工作的罚款现在，但如果我不小心使用'firsta'作为我的class_number，整个事情可能会崩溃，也许会出现一个难以发现的错误。

所以，现在我在想两件事。我绝对想尽可能检查一些事情，但我不喜欢把“引发RuntimeError”，因为它使代码更丑陋。并使其运行速度变慢。那么，我认为后者是可以忍受的，因为检查意味着更好的代码。

但是，我不喜欢丑陋。我正在考虑创建一个单独的ExceptionHandling模块，以便进行这种验证。

在这个例子中，我想检查class_number是'first'，'second'还是'third'。

，而不是像这样：

raise RuntimeError unless ['first', 'second', 'third'].include?(class_number.to_s)

也许我可以写一个简单的模块（可能就像是一个Python的装饰），这将使这件事情更好的阅读，我认为是更漂亮的代码，东西如：

validates class_number, :inclusion => ['first', 'second', 'third']

有点像标准模型验证器。

您对此有何看法？这是一个好主意吗？你会如何对待Rails中的一些错误处理？

来源

2011-03-24 Spyros

class_number是做什么的？ – edmz 2011-03-24 06:48:54

它只是一个函数参数，用于拾取第一个，第二个或第三个散列（在本例中，只有第二个散列存在于函数中，但会添加更多散列）。根本不用担心。 – Spyros 2011-03-24 06:52:18

验证 - 在你给出的例子中，你没有有引发异常。如果class_number不是“first”，“second”，“third”之一，你可以简单地返回false。并检查方法被调用的响应。这种方法是验证方法。

异常 - 当可能导致错误的原因不是由于错误的用户输入，而是因为在您的逻辑，实施或您无法控制的因素中出现严重错误时引发异常。

尽管这些并不是硬性规定，他们更多的是我通常遵循的指导方针。

在上面的例子中，它取决于class_number来自何处。它来自用户输入吗？我会做一个验证。如果它不应该来自用户输入，我会引发异常。此外，您不必简单地提出RuntimeError。你可以设计你自己的异常类。在你的情况，有点像，

class InvalidClassNumber < RuntimeError 
end

，做除非[ '第一'， '第二'， '第三'。包括什么呢？（class_number.to_s）提高InvalidClassNumber，“类号可以为'我们得到了＃{class_number.to_s}“ end

如果你调用这个方法，你可以将它解救出来，做任何你需要做的事情来处理它。

begin 
    @profession = @user.profession(class_number) 
rescue InvalidClassNumber => e 
    # Do whatever you need to 
    logger.debug e.message 
    # redirect somewhere, or whatever 
end

自定义异常类让您灵活精确地处理那些你期待的，而不是处理一般异常喜欢RuntimeError，例外。您可以在应用程序中拥有尽可能多的异常类。你甚至可以使用::给他们一个名字空间。 Profession::InvalidClassNumber < RuntimeError。

来源

2011-03-24 08:16:52 Chirantan

你好Chirantan和thanx的回复非常丰富。我仍然认为开始救援的结局处理相当丑陋，不能说出真相。你如何评价我在问题中描述它的方式？（请记住，在这种情况下，class_name来自我，程序员）。也许我可以尽可能为用户输入和程序员输入进行验证。你认为这是一个好主意吗？ – Spyros 2011-03-24 09:40:14

异常处理对我来说依然很干净，并且可能是通过程序传递错误消息的最明智的方式。如果我们走你的路线，那么如何将验证信息传递回被调用的地方呢？您可能必须遵循活动记录验证模型。我仍然会建议这种情况的例外情况。我通常尽量避免它们，但是你的看起来像是一个典型的异常处理案例。 – Chirantan 2011-03-24 12:28:13

我实际上正在考虑使用上面提到的“validates”思想，并使用异常实现。因此，'验证：包含的class_number'，如果不包含，实际上会引发异常。这样，所有的背景资料，如消息和进一步处理都会发生在模块内部。 – Spyros 2011-03-24 17:29:26

在Rails中处理奇怪异常的最佳做法是什么？

回答

相关问题