回答:
技術的には、1つ目はメッセージをに設定してRuntimeErrorを発生させ"foo"、2つ目はメッセージをに設定して例外を発生させます"foo"。
実際には、前者を使用したい場合と後者を使用したい場合には大きな違いがあります。
簡単に言えば、あなたはおそらく必要RuntimeErrorありませんException。引数のないレスキューブロックはをキャッチしますがRuntimeErrors、Exceptions はキャッチしません。したがってException、コードでを発生させた場合、このコードはそれをキャッチしません。
begin
rescue
endをキャッチするExceptionには、これを行う必要があります。
begin
rescue Exception
endこれは、ある意味でExceptionは、RuntimeErrorから回復するためにさらに多くの作業を行う必要があるため、はaよりも「悪い」エラーであることを意味します。
したがって、どちらを使用するかは、プロジェクトのエラー処理方法によって異なります。たとえば、私たちのデーモンでは、メインループに空のレスキューがありRuntimeErrors、それをキャッチして報告し、続行します。ただし、1つまたは2つの状況では、デーモンが本当にエラーで死ぬようにしたい場合はException、「通常のエラー処理コード」を直接通過するを発生させます。
また、ライブラリコードを記述している場合は、おそらくRuntimeErrorでなくがException必要です。ライブラリのユーザーが、空白rescueブロックがキャッチできないエラーを発生させると驚いたり、理由を理解するのに時間がかかるためです。
最後に、RuntimeErrorはStandardErrorクラスのサブクラスであり、実際のルールは、raise どのタイプのオブジェクトでも可能rescueですが、デフォルトでは、から継承するもののみをキャッチするということStandardErrorです。他のすべては特定でなければなりません。
StandardError。のような数行よりも複雑である必要はありませんclass MissingArgumentsError < StandardError; end。
raise
raise( string )
raise( exception [, string [, array ] ] )引数がない場合、例外が$!発生するRuntimeErrorか、if $!がnilの場合に発生します。String引数を1つ指定するRuntimeErrorと、文字列をメッセージとしてaが発生します。それ以外の場合、最初のパラメータはExceptionクラスの名前（またはException例外が送信されたときにを返すオブジェクト）である必要があります。オプションの2番目のパラメーターは、例外に関連付けられたメッセージを設定し、3番目のパラメーターはコールバック情報の配列です。例外はbegin...endブロックのレスキュー句によってキャッチされます。
raise "Failed to create socket"
raise ArgumentError, "No parameters", caller
RuntimeError < StandardError < Exception[2]したがって、その2番目のコードブロックは、例外とRuntimeErrorの両方をキャッチします[3] 「裸の」レイズとレスキューがその特定の例外で動作するのは興味深い/奇妙です[4]経験則では、RuntimeErrorをクライアントコードにレイズしますが、自分のコード内で自分のカスタム例外をレイズしてレスキューしますか？