2011-01-28 10 views
11

レールプロジェクトでカスタム例外定義を保存する従来の場所は何ですか?

class ThingExploded < StandardError; end 
class ThingIsMissing < StandardError; end 

これらを維持するには良い場所です?のような自分自身のカスタム例外を作りますか私はlib/exceptions.rbを検討していました...そして、どういうわけか、それらを使っているコードにもっと近づける方が適切ならば熟考してください。

+1

タグを「飲み込まれた例外」または「例外」にしますか? –

+0

固定、ありがとう:) –

+7

Railsのデザインは、あるディレクトリに物を入れて報酬を与え、他の場所に置くことを罰します。したがって、Railsプロジェクトに何かを置くべきかについての客観的な助言を与えることができます。私はこの質問を閉じるべきではないことに同意しない。 –

答えて

1

私はapp/models/model_name/exceptions.rbと一緒にモジュールの内部に置いています。

+1

単一のモデルでのみそれらを使用する限り。 – EasierSaidThanDone

+1

あなたは昇給を意味するのに使っていますか?それで私は同意したと思う。 –

17

私は恐らくlib/exceptions/thing_exploded.rbと一緒に別のファイルに保管しています。

+0

各例外を別々のファイルに保存する理由は何ですか?例外クラスはかなりシンプルなので、1つの場所に保持するほうがよいでしょうか? – mrzasa

+1

@mrzasa 1つのクラスで使用されるローカル例外を定義する場合、別々のファイルに移動する必要はありません。しかし、アプリケーション間で例外を共有したい場合、これはlibが自動ロードされたときに私が推奨するアプローチです。しかし、今ではそれらをすべて1つのファイルに入れて、[ActiveRecordはそれをどうするか](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/errors)のように明示的に要求します。 rb)。 –

+0

@PeterBrown間違いなくアプリケーションの本質的な部分なので、 'lib'ではなく' app'のどこかに表示されるはずです。 – skalee

9

例外が非常に厳しい場合を除き、救助されるべきではないから、Exceptionからサブクラス化することは適切ではありません。このようfatalNoMemoryErrorなど

例外はExceptionのサブクラスなので、あなたがThingExplodedThingIsMissingを処理するコードのようなrescue Exceptionを持っていた場合、あなたは最高の一人で残っているもののすべての種類を救出することでしょう。

StandardErrorからサブクラス化する方が良いです。

+0

'レスキューException'もそれらをキャッチします:https://gist.github.com/3c43788eabaa52ae9b98 –

+0

'レスキューException'はすべてをキャッチします、 'RuntimeError'を捕まえるだけの裸の' rescue'を考えているのでしょうか?ここでいくつかの興味深い議論:http://stackoverflow.com/questions/4800698/what-is-the-difference-between-raise-foo-and-raise-exception-newfoo –

+0

もう少し実験をしましたか?裸の 'レスキュー'が救助されるでしょうか'StandardError'とそれのサブクラスです。 'レスキュー例外 'はあらゆる種類の例外を救済します。私はあなたのアドバイスをよく理解していると思います。私はあなたが私のコードで 'レスキュー例外 'を使うと仮定していたと思います。私はしません。私はいつも特別なカスタム例外を救済し、すべての「例外」を救済し、開発者に報告し、それらをユーザから隠す高レベルにまで、より厄介な例外をトリクルアップさせます。 –

関連する問題