Errorは、throwしてほしい・・・
ライブラリというかクラスというか関数というか。とにかく、誰かほかの人も使うような処理ではエラーをthrowしてほしいと思います。
＃ ほかの人じゃなくてもthrowしましょう・・・
内部で1度はキャッチするとしても、とにかくthrowしてほしいです。
そのエラーでどうしなきゃいけないかを決めるのは、ライブラリの作成者じゃなくてライブラリの使用者ですよね。
想定できるエラーで、それによって何かするのなら、catchするだろうし。
想定範囲外のエラーならば、本当は落とさないといけないと思うのです。
そこでがんばって、データが壊れるとかは・・・・（涙）
クラスもそう。関数だって。
内部でエラーのメッセージボックス出して、正常終了させたりとか、何も残さないで正常終了させたりとか・・・は、やめましょうよ。（涙）
そんな僕も昔は、VB6でよくやってしまいました。
「とにかくアプリケーションを落とすな！」
ということを教えられてきたので、On Error GoTo HOGEHOGEでとにかく飛ばしていました。
クラスとかライブラリでも。
それが正しいとさえ思っていたころもあったのです。
＃ ソースが公開されていてよかった・・・修正できる。
投稿日時 : 2005年7月19日 12:09
Tweet
コメントを追加
# re: Errorは、throwしてほしい・・・ 2005年7月19日 19:44 菊池
>そのエラーでどうしなきゃいけないかを決めるのは、ライブラリの作成者じゃなくてライブラリの使用者ですよね。激しく同意
使用者でかつ「制御の責務」をもつものが正しいですね。
# re: Errorは、throwしてほしい・・・ 2005年7月19日 20:28 社本＠ワック
エラーが返された(throw)としても、呼び出し側から正しく対処できる構造になってない場合もあるけどね。# re: Errorは、throwしてほしい・・・ 2005年7月19日 20:59 菊池
壊れたObjectにならないようにって奴ですね。例外安全性の議論とかなつかしいわぁ。
# re: Errorは、throwしてほしい・・・ 2005年7月19日 21:12 社本＠ワック
(インスタンスが)正しい状態を保てるように、ちゃんと設計するか、シンプルにするのが、一番でしょうね。あとは～、コンストラクタ内の例外処理についての議論があるかなぁｗ
# re: Errorは、throwしてほしい・・・ 2005年7月19日 23:11 買太郎
出来れば、例外クラスを一緒に作って欲しいってのは、欲張りでしょうか？よくUserからこんな情報がログで見れるようにって、依頼があるので、言われそうな部分はその例外の中に、先に取り出しやすくして、格納するように心がけています。
# re: Errorは、throwしてほしい・・・ 2005年7月19日 23:33 みゃみゅ玉子
たくさんコメントが！！皆様、ありがとうございます。
throwされた例外オブジェクトが壊れてる場合もあるんですね。
＃ そんなこと考えたこともなかった・・・orz
そんな複雑な例外は発生させないとは思うのですが、たとえば、throwするオブジェクトがthrowの前に破棄されてるなんてこともありえるんですよね。
＃ catchまでいかない気がしますが・・・
例外クラスは、考えられる範囲でオリジナルなエラーならばセットで作ると思うんですけど、どうなんでしょう？
ファイルが見つからないエラーなら、例外クラスがきっとあるので作らないけど、
じゃんけんであいこになったらエラーって仕様なら、「あいこException」クラスを作るといった感じですね。
＃ エラーばかり発生させるのもよくないとは思いますが。
# re: Errorは、throwしてほしい・・・ 2005年7月20日 1:36 買太郎
例外オブジェクトが壊れる事ってあるんですか？どんな時か、ちょっと分からないです。参考までに教えてほしい～です。
今まで作ったなかでは、
基本的なDataBaseでのアクセスするクラスとかで、SQL発行などで異常が出た場合に、SQL文の内容とかをそのクラスでセットして置くとかですかね～
（多分イメージしにくいですかねｗ）
でも、例外ばっかり発生させるのは、良くないですね。
まだ、よく分かってない時は、なんでも例外で飛ばしちゃうように実装した事あります^^;
DataBaseにSelectかけて該当データが無いだけ例外飛ばしてたので、今考えると。。。ごめんなさいです
想定されるエラー（仕様上エラーじゃないものも含む）と、バグや環境が変だとか、どうしても処理出来ない例外とを分けてあげる様にしています。
# re: Errorは、throwしてほしい・・・ 2005年7月20日 9:41 菊池
いや例外オブジェクトが壊れるんじゃなくて、例外の出た時点で発生元のオブジェクトが壊れるというべきか。フィールド変数になんか書き込んでからIOに行って例外が出たとかで、フィールドとIOされる外部は同期がとれてない事になりますよね。
同期が取れてない事自体を壊れたとみなせばオブジェクトは壊れてます。
Openに失敗して例外飛んできたのに、Closeが要求される（しかもCloseするとハンドルとかがちゃんと無くて死ぬ）なんてのが壊れるオブジェクトの典型ですね。
# re: Errorは、throwしてほしい・・・ 2005年7月20日 20:24 社本＠ワック
> いや例外オブジェクトが壊れるんじゃなくて、例外の出た時点で発生元のオブジェクトが壊れるというべきか。です。
壊れるよりも、オブジェクト内の整合性がとれていないといったほうが分かりやすいかもしれませんね。
# re: Errorは、throwしてほしい・・・ 2005年7月21日 12:54 買太郎
ありがとうございます。菊池さん、社本＠ワックさんの説明で理解できました^_^;
# re: Errorは、throwしてほしい・・・ 2005年7月21日 13:26 みゃみゅ玉子
> でも、例外ばっかり発生させるのは、良くないですね。まだ、よく分かってない時は、なんでも例外で飛ばしちゃうように実装した事あります^^;
いきなりメッセージボックスが出たり、沈黙を守っていたりするよりは例外を投げてほしいです。（涙）
> DataBaseにSelectかけて該当データが無いだけ例外飛ばしてたので、今考えると。。。ごめんなさいです
場合によりますが、
「該当データが、この時点で無いのは絶対におかしいよ！」
という意味であれば、例外もOKなのかと思います。
＃ っていうか例外にしないと・・・
例えば・・・どんなのがあるだろう・・・？
ユーザー登録したら、ユーザー基本情報とユーザー詳細情報にデータを作成する仕様なのに、詳細情報を持ってこようとしたら無い場合とか・・・
これは例外でいいですよね。
「ユーザー情報が壊れてるException」で。
でも、月間レポートを作成するときに
「4日のデータが1件も無い」
で例外発生はNGなのかなぁ・・・と。
# re: Errorは、throwしてほしい・・・ 2005年7月21日 15:06 買太郎
ごめんなさいしたのは、全てのＤＢへのアクセスをラップしているクラス内部で、データ無しは例外だよって実装したんで、正常な時は、その例外のみキャッチして処理続行するように組み込みました。（恥なんで、今考えると、正常な処理の流れでも例外出まくりで効率わるいな～っと