消えてなくなれよ >オブジェクト指向 part.2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/03/22(日) 06:57:59http://pc11.2ch.net/test/read.cgi/tech/1198822420/
0403デフォルトの名無しさん
2009/05/21(木) 07:34:230404デフォルトの名無しさん
2009/05/21(木) 07:35:52下手な書き方だな。
0405デフォルトの名無しさん
2009/05/21(木) 07:50:06関数の外に例外を投げることは極力やらないようにしてる。
関数外に例外を投げるのは、例外を出す関数と例外を処理する関数が密接に関連してて、
どういうケースでどういう例外が出て、どう処理すればいいのかをそれらの関数全体で
設計するときくらいかな。
0406デフォルトの名無しさん
2009/05/21(木) 07:57:31じゃなくてそんなことしないほうがいいんじゃないの?
0407405
2009/05/21(木) 08:04:580408デフォルトの名無しさん
2009/05/21(木) 08:22:01それでは済まない場合、例えばデータベースの処理でロールバックしなきゃいけないなど、
そんなときだけ途中レベルで例外処理して、例外を再送出している。
例外使っててドキュメントが増えて難儀するなんてことはない。
>>402
396のSendMessageが呼び出す関数で例外が発生するようになるというのは仕様変更
関数の仕様変更に呼び出し側が対応するのは例外・エラーリターンどちらでも同じ
0409デフォルトの名無しさん
2009/05/21(木) 08:25:48志しでいい場合は例外でもいいかもね
0410デフォルトの名無しさん
2009/05/21(木) 08:32:31エラー起きても終わらせたくないときは途中レベルで例外処理
エラー処理を荒くもできるし細かくもできる
0411デフォルトの名無しさん
2009/05/21(木) 08:34:42ScalaのOption、HaskellのMaybeみたいな奴だろ。C#のNullableも近い。
0412デフォルトの名無しさん
2009/05/21(木) 08:35:39それは、エラーハンドリングしなくていいプログラムの場合だろ?
SendMessageのような通信もののばあい、エラーが起きたらそのコマンド
再送するけど、数回繰り返してだめだったら最初からリトライする。
というようなわりとめんどうなエラーハンドリングしないといけないことがおおい。
0413デフォルトの名無しさん
2009/05/21(木) 09:02:45お互いに、「そうじゃない、例外処理は場合による」なんて言ってたらまとまる訳無いじゃん
0414デフォルトの名無しさん
2009/05/21(木) 09:07:51前提の整理がされてないから当然の流れ
0415デフォルトの名無しさん
2009/05/21(木) 09:49:36「インスタンスを作って」って言ってるけどさ、処理の内容はソースで書くじゃない
動的な配列の確保と違って、その場限りって事は無いだろ
0416デフォルトの名無しさん
2009/05/21(木) 09:59:500417デフォルトの名無しさん
2009/05/21(木) 10:09:350418デフォルトの名無しさん
2009/05/21(木) 10:11:350419デフォルトの名無しさん
2009/05/21(木) 10:32:58俺は、プログラムが異常終了しないようにする保険みたいなものと考えてるけど
0420デフォルトの名無しさん
2009/05/21(木) 12:24:500421デフォルトの名無しさん
2009/05/21(木) 15:23:45結果を戻す方法に返値と例外の2ラインがあるだけでも使い勝手が
あると思うけど。
例えば正常な返値としてnull等々も返しうる関数で、しかも時には
エラーも返したい、という場合はどう書くのかな。
0422デフォルトの名無しさん
2009/05/21(木) 17:47:16> SetupDeviceの中身なんて関係ねーんだよ
> 呼び出し側優先で考えて作ってくれよ
>>399の例で言えば
SetupDevice1からSetupDevice9まで
全部「呼び出し側」なことに気付けカス
0423デフォルトの名無しさん
2009/05/21(木) 17:49:18例外を投げるように作っておけば、
エラーコードを返すほうのバージョンは簡単にラッパーで書ける。
0424デフォルトの名無しさん
2009/05/21(木) 17:56:56はぁ?
なんで関数の中までみないといけないの?
この時点でおかしいじゃん
馬鹿なんじゃない?
0425デフォルトの名無しさん
2009/05/21(木) 18:00:57ほしいかなぁ。
チェーンの途中でnullとか出力されるとヌルポが怖くて使えん。
0426デフォルトの名無しさん
2009/05/21(木) 18:20:06>>424は関数の内部の実装なんか知ったこっちゃねぇ、ただ
APIとしてユーザに公開される関数に関しては例外を投げるな、
エラーコードで戻せ、と言いたいんじゃ無いのかな。
気持ちとしては分からないでもない。
でもどちらが良いかは実際の関数の使われ方によるんじゃないのかな。
例外で投げてもらった方が使い勝手が良い場合もあるし。
0427デフォルトの名無しさん
2009/05/21(木) 19:22:45使われ方?はぁ?
言葉に気をつけろよ
1回潜ったら100回潜っていく必要があることと等価だろ?
関数が呼んでる関数の中で呼んでる関数の仕様に翻弄されてちゃ
いつまでたっても完成なんかしないよ
0428デフォルトの名無しさん
2009/05/21(木) 19:51:42Javaもその点が残念すぎる
0429デフォルトの名無しさん
2009/05/21(木) 20:40:57ヌルポも立派な例外だろ。
0430デフォルトの名無しさん
2009/05/21(木) 23:10:09例外処理は重いというのは良くみるけれど、今ひとつぴんとこない。
従来の関数の戻り値を見るやり方に比べて重いのは、例外発生時に例外オブジェクトを
newするという点だけだと思うんだけど間違ってる?
0431デフォルトの名無しさん
2009/05/21(木) 23:26:51かまうな
レスをつけるな
0432デフォルトの名無しさん
2009/05/21(木) 23:33:350433デフォルトの名無しさん
2009/05/21(木) 23:46:16拾い溢しを防ぐような使い方がいい
先にアプリケーションがあって、ライブラリが後から実装みたいな開発の仕方なら
例外中心のほうがいいけど
0434デフォルトの名無しさん
2009/05/22(金) 00:00:11Javaの場合スタックトレース(呼び出し階層)を生成するから遅いよ。
復帰可能かつ精度が求められない演算(たとえばストリーミングで動画再生とか)での
エラー処理って言うのは、わざわざスタックトレース生成せずにそのブロックだけ
空の値を返すとか前回の演算結果をそのまま返すとかしたほうがいい。
結局はエラー処理をどう扱うかなんてケースバイケースなんだけど、
そのケースの要件とか許容範囲を精査せずに実装すると切ないことになる。
0435デフォルトの名無しさん
2009/05/22(金) 00:11:19誰もそんなこと聞いてねぇよ
消えろよ馬鹿
0436デフォルトの名無しさん
2009/05/22(金) 00:14:480437デフォルトの名無しさん
2009/05/22(金) 00:42:47時代遅れ
0438デフォルトの名無しさん
2009/05/22(金) 00:46:130439デフォルトの名無しさん
2009/05/22(金) 05:26:49自分の失敗を例外処理のせいにしてヤツアタリしている、
ということで了解。
0440デフォルトの名無しさん
2009/05/22(金) 06:15:39は?
日本語読めないクズは黙ってろよ
0441デフォルトの名無しさん
2009/05/22(金) 06:18:580442デフォルトの名無しさん
2009/05/22(金) 07:20:250443デフォルトの名無しさん
2009/05/22(金) 07:47:06アフォだねえ
> if(!SetupDevice()){
> //エラー
> }
エラーは一種類しかないのかいw
> この仕様でソース書き続けたらクラス使ってあるたびに
> 元のソースかドキュメント確認して例外かえすかどうか確認しなくちゃいけないんだぞ
どんなポンコツIDE使ってんだよ。
どのメソッドがどんな例外をthrowするかなんてIDEがチェックできるだろ。
そのためのthrows句だ、カス。
そもそも、エラー返す場合のほうがどの関数がどんなエラーコードを返すか、
元のソースかドキュメント確認しなきゃならないだろ。
> 超面倒くせぇセンスねぇ時間ばかり使ってぇなにも産まねぇw
その言葉、そっくり
> if(!SetupDevice()){
> //エラー
> }
こういうアフォなことやる底辺PGに返してやるよ。
0444デフォルトの名無しさん
2009/05/22(金) 07:55:160445デフォルトの名無しさん
2009/05/22(金) 08:06:05JavaのEOFや、VB6のCollectionのキーのない要素にアクセスしたときの例外は
例外の乱用だと思う。
0446デフォルトの名無しさん
2009/05/22(金) 08:06:120447デフォルトの名無しさん
2009/05/22(金) 08:35:46下手にNullなんぞ返されるより、例外を上げてもらったほうがナンボかマシだなあ。
0448デフォルトの名無しさん
2009/05/22(金) 08:36:19一連のレスを読めばその辺の返答は全部書いてあるんだけど?
0449デフォルトの名無しさん
2009/05/22(金) 08:41:07そのことごとくが的外れであることが指摘されているわけだが?
0450デフォルトの名無しさん
2009/05/22(金) 08:50:36一方は、「例外を使う必要が有るところで例外を使おう」
お前ら馬鹿だろ?
0451デフォルトの名無しさん
2009/05/22(金) 08:53:240452デフォルトの名無しさん
2009/05/22(金) 08:57:15例外についても見直せて良かったんじゃない?
やっぱりおれは例外使うけど
0453デフォルトの名無しさん
2009/05/22(金) 10:19:040454デフォルトの名無しさん
2009/05/22(金) 10:58:24その前に、OOの話をしていて唐突に例外に話題が移る時点で。
0455デフォルトの名無しさん
2009/05/22(金) 11:04:28> どのメソッドがどんな例外をthrowするかなんてIDEがチェックできるだろ。
> そのためのthrows句だ、カス。
どの関数が throwするかじゃなくて、実行時にどの関数が実行されるかが問題。
0456デフォルトの名無しさん
2009/05/22(金) 11:27:08インスタンスが分からない人たちだからしょうがないね
0457デフォルトの名無しさん
2009/05/22(金) 11:39:29言語境界とかOS境界を越えて同じバイナリを使うのが困難すぎる
0458デフォルトの名無しさん
2009/05/22(金) 12:02:34メソッドの実装を変更すると、投げられる可能性のある例外が変わる。
その例外を垂れ流せばインタフェースが変わってしまう。
でも、インタフェースが実装に依存するのはよくないから、
全ての例外をメソッドの内部でcatchしておくべき。
問題は、何かのミスで例外が外に漏れ出したりしないことを保証できるかどうか。
0459デフォルトの名無しさん
2009/05/22(金) 12:15:48何番のレス?
>問題は、何かのミスで例外が外に漏れ出したりしないことを保証できるかどうか。
全ての例外を握りつぶすことは簡単、例外が発生したらreturn falseするのも簡単
} catch {
return false;
}
0460デフォルトの名無しさん
2009/05/22(金) 12:27:15処理系にもよるだろうけど、
中でスレッド起こしてたら、例外は別ルート通っていってキャッチできなくね?
0461デフォルトの名無しさん
2009/05/22(金) 12:36:13例外ってスレッドで独立してないか?
呼び出したルーチンに例外は漏れんと思うが
0462デフォルトの名無しさん
2009/05/22(金) 12:45:310463デフォルトの名無しさん
2009/05/22(金) 12:51:05だから、処理系によると書いた。
少なくとも、g++では別スレッドからの例外はキャッチできずにプログラム自体が落ちた経験がある。
0464デフォルトの名無しさん
2009/05/22(金) 12:51:090465デフォルトの名無しさん
2009/05/22(金) 12:57:12メソッドがどんな例外を投げるか
っていうのは、インタフェースに関わることで、
インタフェースはオブジェクト指向の本質と言っても過言ではない。
0466デフォルトの名無しさん
2009/05/22(金) 12:57:160467デフォルトの名無しさん
2009/05/22(金) 13:00:50> インタフェースはオブジェクト指向の本質と言っても過言ではない。
なぜか、オマイのことだけは信用していい気がした。
0468デフォルトの名無しさん
2009/05/22(金) 13:05:03C++やLispでCLOSを使ってると出て来ないよね?
0469デフォルトの名無しさん
2009/05/22(金) 13:10:35例外は例外的な事態が発生した時に発生させるものなので、
基本的にパフォーマンスは問題にならない。
もそパフォーマンスが問題になるほど頻繁に例外を発生させてるのなら、
例外の使い方が間違ってる。
0470デフォルトの名無しさん
2009/05/22(金) 13:18:000471デフォルトの名無しさん
2009/05/22(金) 13:24:35速度重視で真偽値を返す奴との2通り用意してある事が多いでしょ。
0472デフォルトの名無しさん
2009/05/22(金) 13:31:39予測可能な例外って意味わかんないよ!
0473デフォルトの名無しさん
2009/05/22(金) 13:38:00いや、ifを書くとコードがごちゃごちゃするから、例外でまとめてキャッチするという手段を使うと良い場合もあるんだよ。
0474デフォルトの名無しさん
2009/05/22(金) 13:39:46ってやった方がシンプルで安全な場合もある。
0475デフォルトの名無しさん
2009/05/22(金) 13:56:53ifが嫌ならswitchを使うといいwww
0476デフォルトの名無しさん
2009/05/22(金) 13:58:43根本解決になってない
0477デフォルトの名無しさん
2009/05/22(金) 13:59:07ま、キレイに書きたい気持ちは分かるけど…
本当にそれは例外じゃないとだめなの?
0478デフォルトの名無しさん
2009/05/22(金) 14:03:52お前に言われたくないが、
ErlangスタイルでC++とかでプログラミングするなら例外を使うときれいにまとまるな。
0479デフォルトの名無しさん
2009/05/22(金) 14:11:19例外がどこから飛んできたのかわかりにくくなる。
全然関係ない場所から偶然同じ型の例外が飛んできたら嫌じゃん
0480デフォルトの名無しさん
2009/05/22(金) 14:23:07必要があれば部分的に例外処理、荒くも細かくもできる
0481デフォルトの名無しさん
2009/05/22(金) 14:23:23例外が投げられた場所に応じた細かい対応を記述したいの
なら狭い範囲を囲めばいいじゃん。
広い範囲を囲むのは、その範囲内で投げられた例外に対して
同じ処理で対応出来る時。
所詮書き分けで対応出来る話でしょ。
0482デフォルトの名無しさん
2009/05/22(金) 14:34:350483デフォルトの名無しさん
2009/05/22(金) 14:39:53BadArgumentExceptionとかするのはいかがなものか。
0484デフォルトの名無しさん
2009/05/22(金) 14:41:50そりゃ例外云々じゃなくてGOTOだからダサいんでしょ。
関数呼び出しのたびにIF書いてGOTO飛ばしたらもっとダサくなる。
>>483
素敵だと思うけど。
0485デフォルトの名無しさん
2009/05/22(金) 14:56:42ON ERROR GOTOは、GOTOと書かれてるからダサいんじゃない、エラー処理の本質がGOTOだって事を嫌でも思い知らされるからダサいんだよ
0486デフォルトの名無しさん
2009/05/22(金) 15:06:02オブジェクト プロバイダのガイダンス
例外を、単なる別のエラー処理技法のように扱ってはいけません。
エラーコードを返したり、グローバル変数の設定したりすることと同レベルだと思ってはいけません。
例外は、それを取り巻くコードの構造と意味を、根底から覆します。
例外は、プログラムの実行時セマンティックを一時的に繋ぎ変え、通常実行しているコードを迂回し、
こういう状況でなければ決して実行されないコードを動作させます。
例外は、エラー状態を認知させ、プログラムの死という罰則を用いてその状態を改めようとします。
このように、例外には単純なエラー処理を超えた特性があります。
これらの特性を必要としない、理解しない、あるいは文書化したくないなら、例外をスローしてはいけません。
例外以外のエラー処理技法を探してください。
スローすることに決めたなら、すべての因果関係を理解してください。
あなたの設計が、あなたのコードを使用する他のユーザーに、潜在的に多大な影響を与えることを承知していてください。
例外はインターフェイス契約の一部なのです。
どの種類の例外をインターフェイスからスローするのか、どのような場合に例外をスローするのか、
なぜスローするのか、これらを完全に文書化しなければなりません。
そして、その文書を例外仕様として、コードの中に記述することを十分考えてください。
0487デフォルトの名無しさん
2009/05/22(金) 15:10:190488デフォルトの名無しさん
2009/05/22(金) 15:11:54ですね
わかります
0489デフォルトの名無しさん
2009/05/22(金) 15:12:14エラーの発生した処理と遠く離れたところにcatchがあるのは
現代のスパゲティプログラムといえるね
0490デフォルトの名無しさん
2009/05/22(金) 15:16:01こうも書いてあるね
>例外をスローすべき十分な理由があるなら、進んでその例外をスローして、
>それを文書化すればよいのです。例外をスローするのが当然の場面で、
>例外のスローを回避する方法を発明する必要はありません。
0491デフォルトの名無しさん
2009/05/22(金) 15:47:41仕様、仕様とあるように、例外を投げる仕様と、
投げなくて問題があれば単にnullを返す仕様。
どちらが当然か、という話になるのか?
そういう話じゃないのか?
0492デフォルトの名無しさん
2009/05/22(金) 16:03:49引数で「例外ファクトリ」を指定する仕様にすればスローするのが当然だよね
0493デフォルトの名無しさん
2009/05/22(金) 18:13:48まあ、そうじゃねぇと邪魔でしょうがねぇよな
0494デフォルトの名無しさん
2009/05/22(金) 19:39:15このスレの例外議論を終了したいと思います。2009年5月22日(金)
0495デフォルトの名無しさん
2009/05/22(金) 19:52:020496デフォルトの名無しさん
2009/05/22(金) 21:35:470497デフォルトの名無しさん
2009/05/22(金) 21:37:450498デフォルトの名無しさん
2009/05/22(金) 21:37:490499デフォルトの名無しさん
2009/05/22(金) 21:55:130500デフォルトの名無しさん
2009/05/22(金) 22:03:550501デフォルトの名無しさん
2009/05/22(金) 22:10:28エラーになるかもなんていっていたら何もできやしない。
俺はエラー処理なんて一度も書いたことねぇ。
やれるって信じたら絶対できる。
0502デフォルトの名無しさん
2009/05/22(金) 22:20:20■ このスレッドは過去ログ倉庫に格納されています