Ruby 异常

Ruby

大体上来说，异常就是一个包含了错误场景信息的对象，本篇简单来说下 Rails 的异常

大多时候，其信息仅仅是在程序崩溃之前将可读的错误信息发送至控制台，它们还可以被 rescue 截获处理。同时特定的异常类型也代表着特定的错误恢复方式，某些时候这意味着终止当前的任务并记录错误信息，更加详细的异常可能允许你改变程序的状态并重试。为了从错误中恢复，你需要能够区分各种可能的错误条件。

不过，Ruby 中的异常使用起来简直不要太简单，一个常见的现象就是使用 raise 来引发异常：

raise('coffee machine low on water')

在Ruby 中，raise 方法有着不同的风格，当接收单个字符串参数时，raise 会创建一个 RuntimeError 并会使用这个字符串作为错误信息，其等价于：

raise(RuntimeError, 'coffee machine low on water')

使用类作为 raise 的第一个参数而不是字符串将会创建这个类的异常对象，并将其对象抛出。这非常有用，不过除了当你希望终止程序时，抛出 RuntimeError 是很模糊难懂的，它和原始的 ‘hi，something went wrong’ 错误没有什么差别。因为你编写的代码是给别的程序员用的，这时 RuntimeError 是个很糟糕的选择。

如果你决定抛出异常，就因该为他创建一个新类型
1. 新的异常类必须继承标准异常类，任何其他的尝试都会导致一个 TypeError，它会将你最初想要抛出的异常丢掉。
2. 标准异常类形成了一套以 Exception 为基类的继承体系。但是 Exception 以及它的许多子类被认为是低级别的错误，通常他们会导致程序的崩溃。多数的标准异常类应该继承自 StandardError 。
3. 就通俗易懂（并不是硬性规定），通常异常类应以 ‘Error’ 来作为后缀。

关于第二条从 StandardError 继承的另一个原因是 rescue 语句的默认行为，rescue 在处理异常时是可以省略异常类的名称的，此时它将会拦截任何 StandardError 类及其子类的异常。

另外编写定义异常类的时候，要记住在基类初始化的时候调用 super 方法，最好在调用时将错误信息作为参数。这样上游的 Exception 类就可以设置一些内部的实例变量，包括错误信息。需要注意的是，在 initialize 方法中设置错误信息时，如果在 raise 方法中再度设置错误信息将会覆盖原本在 initialize 中设置的那条。