消えてなくなれよ >オブジェクト指向 part.2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/03/22(日) 06:57:59http://pc11.2ch.net/test/read.cgi/tech/1198822420/
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:200503デフォルトの名無しさん
2009/05/22(金) 22:30:20投げる側では「ある条件のとき例外を投げる」
として、普通におもっくそ想定を置いている。
例外でもなんでもない。
ゼロで割る？ ファイルがない？ 数値化できる文字列じゃない？
んなもん事前に調べれ。
0504デフォルトの名無しさん
2009/05/22(金) 23:18:44そんな機能があったことも忘れたよw
0505デフォルトの名無しさん
2009/05/22(金) 23:30:10ファイルの存在を確認してから
開くまでの間に消されるかもしれないじゃないか。
そんなのどうやって事前に調べるんだよ
0506デフォルトの名無しさん
2009/05/22(金) 23:31:26受け手がいなくて死んだりする
リンクのミスとかで他の不具合も出る
投げないにこしたことない
0507デフォルトの名無しさん
2009/05/22(金) 23:32:390508デフォルトの名無しさん
2009/05/22(金) 23:37:36それは「ファイルを消すな」という問題じゃね？
プログラムが責任を持つのはせいぜい、
プログラム内での排他処理でよくね？
OSレベルのことで困れば、
オチてプログラム呼び出し側で責任取らせればよくね？
呼び出し元の事情を気にするのは、
よくない設計じゃね？
0509デフォルトの名無しさん
2009/05/22(金) 23:45:480510デフォルトの名無しさん
2009/05/23(土) 03:37:44malloc()の返り値のNULLチェックをやっているのやら。
0511デフォルトの名無しさん
2009/05/23(土) 04:13:00> ゼロで割る？ ファイルがない？ 数値化できる文字列じゃない？
> んなもん事前に調べれ。
文句言うまえに、そんな糞パラメータ送ったおまえが調べろよ。
0512デフォルトの名無しさん
2009/05/23(土) 04:47:38a();
v = f();
b();
c(v);
一見正しくみえるが、f()が例外を飛ばすのを忘れていると
例外自体は他でキャッチするのでテストはキチンと失敗するにも関わらず
f()が失敗したのに誤ってa()したり、誤ってb()しなかったりする
OO的に
Any f() {
if (!hoge()) reterun new Error("Can't hoge!");
return fuga();
}
のように正常な経路でメッセージを戻せばその種の不整合問題は発生しづらい
エラー処理を忘れたらc(v)の内部でとまるので原因はすぐわかる
実際はc(v)内部で引数のチェックくらいするからエラーを記録して何もしないという選択もできる
例外投げたらそこで終了だよ
0513デフォルトの名無しさん
2009/05/23(土) 05:33:56Javaの場合、トラップするべき例外をトラップしていなければ
コンパイラがそれを指摘してくれますが何か？
返り値でエラーコードを返す場合にはそうはいきませんなあ。
で、君はmalloc()するたびにちゃんとNULLチェックしてるの？
0514デフォルトの名無しさん
2009/05/23(土) 05:38:46おまえ、本当にマか？
> Any f() {
> if (!hoge()) reterun new Error("Can't hoge!");
> return fuga();
> }
コンパイラさんからreterunって何？って叱られるぞw
> のように正常な経路でメッセージを戻せばその種の不整合問題は発生しづらい
f()の返り値がおかしいかどうかちゃんとチェックしていなければ、
原因をトレースするのが厄介になるぞ。c(v)が悪いのかf()が悪いのかa()が悪いのか
ワケワカラン状態になるのがオチだ。
例外を使えばちゃんとスタック保存してくれているから原因は一目瞭然。
> 実際はc(v)内部で引数のチェックくらいするからエラーを記録して何もしないという選択もできる
空のハンドラ渡すのと何が違うの？
0515デフォルトの名無しさん
2009/05/23(土) 05:41:47>f()が例外を飛ばすのを忘れていると
処理に失敗したのにも関わらず例外を投げ忘れたf()は、返値
として一体何を返すの?
>if (!hoge()) reterun new Error("Can't hoge!");
ここでエラーを返すか例外を投げるか、それだけの違いでは。
if (!hoge())をチェックすべきことが分かっているか否か、大切
なのはその事であって、この事に気づいていればエラーを返す
とか例外投げるとかは単に実装の違いに過ぎないと思う。
>f()が失敗したのに誤ってa()したり、
関数の呼び出し順が間違っているのでは。a()の実行の前提と
してf()の成功が必要なら、f()の後にa()呼ぶでしょ。
これは例外とか返値云々とは無関係な、因果律の問題。
>誤ってb()しなかったりする
何のためにensureやfinallyがあると思っているんだ。
>c(v)の内部でとまるので原因はすぐわかる
止まったときには結局例外が投げられるんじゃない?
>Any f() {
言語にもよるけど、静的型付けの言語の場合には結果と
詳細なエラー情報を共に返値で返すとなると返値の型や
セマンティクスで悩むことは少なく無いと思う。
Anyですか。そうですか。
0516デフォルトの名無しさん
2009/05/23(土) 05:50:56> 言語にもよるけど、静的型付けの言語の場合には結果と
> 詳細なエラー情報を共に返値で返すとなると返値の型や
> セマンティクスで悩むことは少なく無いと思う。
そうそう。存在しないキーでハッシュマップ引いた時に
例外を投げずにNullを返しちゃったりしたら、
ハッシュマップで対応する値がNullだったのか、
ハッシュマップで対応する値がなかったのか、
判別つかないんだよな。
その判別をするための特殊なクラスをつくると、
とたんに返り値の型が問題になる。
Objectとかにしたら、今度は使う側でナローキャスト
してやらなきゃならなくなって静的型のメリットがなくなるし。
0517デフォルトの名無しさん
2009/05/23(土) 06:27:10f()が例外を返すことを書いた時は覚えていた
その例外は別の階層でトラップされるから正しい記述である
が翌日忘れてあるいは別人が修正したとするそんな感じのバグが生まれる話
言語仕様が関数が例外を投げると宣言することを強制しても
例外を戻す関数が他にあれば紛れてしまうでしょ
a()の位置が違うのは分かってワザとそこに書いたの
v=f()のところにエラー処理の記述があればレビューの時に誰か気付くんだよ
0518デフォルトの名無しさん
2009/05/23(土) 07:33:56C#の場合だが例外を発生させないためにTryGetValueがある。
bool result = dictionary.TryGetValue(key,out val);
キーのない値をひくのは通常処理の場合が往々にしてあるからこれも必要と思う
0519デフォルトの名無しさん
2009/05/23(土) 08:49:42「ドキュメントやコメントをちゃんと書きやがれ」
って次元の問題じゃん
0520デフォルトの名無しさん
2009/05/23(土) 09:50:340521デフォルトの名無しさん
2009/05/23(土) 09:52:13GetValueは例外、FindはNo Such Keyを表す何かを返す。
0522デフォルトの名無しさん
2009/05/23(土) 10:23:07もうオブジェクト指向が無くなれとか言う問題じゃなくなってるwww
0523デフォルトの名無しさん
2009/05/23(土) 10:40:46outがなければ例外を投げればいいじゃない(ｷﾘｯ
0524デフォルトの名無しさん
2009/05/23(土) 11:30:50ライブラリが例外を返すようなコードを書くな。書くならそのリスクを覚悟しろってことだ
0525デフォルトの名無しさん
2009/05/23(土) 12:49:19486のリンク先は言ってることが良く分からない。
内容が有益であるのなら、だれか要点をまとめてくれない?
# だらだらした文書である上、罰則だの精神とかの妙な単語が頻出していて
# 頭のおかしなやつが書いたようにしか見えなかった…
# (ソースのインデントの仕方も一番ダメだと思っているスタイルだったし…)
0526デフォルトの名無しさん
2009/05/23(土) 13:00:45実際例外使わないバージョンを書くときにその手の事前チェックの
関数と実処理の関数に分けることは常套だけど、前提もある。
一つはそのハッシュがスレッド間で共有されてたり、データが実は
ネット上にあってそれを参照しに行くような実装ではないこと。
チェックしてから実処理するまでの間にハッシュの内部状態が変わる
可能性があるからね。
もう一つは事前チェックが非破壊的に、しかも低コストで行える事。
例えばXML等のパース。事前に「パース可能か」なんて確認しよう
と思ったら、その後のパース本番と併せて2度XML文書をスキャン
する事になる。
つまり何時でも使える手ではないし、それを回避するために色々工夫
するよりは(ハッシュのロックを取得する関数を追加したり、パース後
にエラーを 取得する関数を追加したり)サクッと例外を投げる仕様に
した方が見た目も使い勝手もシンプルになるケースもある。
0527デフォルトの名無しさん
2009/05/23(土) 13:23:27しっかり読んだうえでまだなにかあるなら
正規ＯＳ買ってＭＳにメールだせよｗ
だいたいあの程度の文章理解できないってありえないだろ
英文なわけでもないし
捻った表現してるわけでもない
0528デフォルトの名無しさん
2009/05/23(土) 13:24:11結局のところは>>450って事だろ
0529デフォルトの名無しさん
2009/05/23(土) 13:25:17全然違うよ
読んでないなら無理やりレスをつけるな
0530デフォルトの名無しさん
2009/05/23(土) 13:26:13そんな細かいこと気にしてるから禿げるんだよ!!!
ってこった
0531デフォルトの名無しさん
2009/05/23(土) 14:34:01> GetValueは例外、FindはNo Such Keyを表す何かを返す。
そしてFindはGetValueを使って実装されている。
例えばPythonなんかはそういう実装。
0532デフォルトの名無しさん
2009/05/23(土) 14:58:560533デフォルトの名無しさん
2009/05/23(土) 15:38:21日本語でおｋ
0534デフォルトの名無しさん
2009/05/23(土) 16:58:12throws NumberFormatException
パラメータ:
s - 構文解析対象の int 表現を含む String
戻り値:
10 進数の引数で表される整数値
例外:
NumberFormatException - 文字列が構文解析可能な整数型を含まない場合
こういうときは例外のほうが素直な気がするね。
intでどうのこうのやりくりしたりするよりは。
0535デフォルトの名無しさん
2009/05/23(土) 17:14:35文字列の数値変換なら、変換不能な場合は素直に0を返したほうが良くね?
例外にする意味が分からん...
エラーとして扱うにしても、エラーにする意味も分からん...
0536デフォルトの名無しさん
2009/05/23(土) 17:18:37解析不能は0として扱うでいい場合もあるけど。
0537デフォルトの名無しさん
2009/05/23(土) 17:27:37まあ現実的にはWin32APIみたく戻り型をBOOLにして
引数側で結果を受け取れば問題ないね
0538デフォルトの名無しさん
2009/05/23(土) 17:29:16そういうのは、Javaなら参照型のInteger、C#ならNullable型とかの抜け道があるし。
0539デフォルトの名無しさん
2009/05/23(土) 17:33:01既に消えてしまったようだ
0540デフォルトの名無しさん
2009/05/23(土) 18:47:32間にobjectのnewとかdeleteが入るとまずいってんでthrow catchにしたわけですよ。
例外を使いたくない奴は使わない、使いたい奴は使うということでいいんじゃないの？
でもthrowした奴は投げっぱなしじゃなくて責任持ってcatchしろよな ボケ！
0541デフォルトの名無しさん
2009/05/23(土) 18:58:11例外を返したければインデクサをそのまま使えばよい
C#では２種類用意されていると言うこと
＞outがなければ例外を投げればいいじゃない(ｷﾘｯ
キーが存在して、値がnullの場合があるからそれじゃダメなんだよ
516も読んでるか？
0542デフォルトの名無しさん
2009/05/23(土) 19:03:11BASICのON ERROR GOTOが先じゃね?
0543デフォルトの名無しさん
2009/05/23(土) 19:04:37受け側はノードが返ったら値を得る
見つからなかったらNULLでいいじゃない
特殊なクラスだとか、おまえら頭悪すぎですよ
0544デフォルトの名無しさん
2009/05/23(土) 19:08:24ちょっとした工夫だな。でも、それでいいと思う。
メソッドの返り値がすべてその仕組みになってたら、
nullか否かで全部扱えるのにな。例外なく。
0545デフォルトの名無しさん
2009/05/23(土) 19:29:26自己紹介乙
0546デフォルトの名無しさん
2009/05/23(土) 19:31:13ノードそのものを渡してしまうと、ちんたらしている間に
ノードの中身を他スレッドとかに書き換えられる恐れも
あるんだよね。
1) Node node = map.getNode(key);
2) if(node != null){
3) chintara();
4) chintara();
5) chintara();
6) chintara();
7) return func(node.value);
8) }else
9) return ERROR;
ちんたらするんじゃね〜とも言いたくなるけど、3〜6の間に
node.valueの値が書き換えられたりnode自体がmapから
removeされていても、文句は言えん。
仮にmap自身が自前で排他制御して複数スレッドのアクセスを
認めるマルチクライアントな実装になっていても、これでは
殆ど意味がない。結局node.valueを取得するまでmapをロック
するコードを毎度クライアント側で書く必要がある。
nodeへの参照ではなくコピーを返すのも一つの手だけど、
それだと処理値をエラーコード付きの構造体でラップして
返すのと大差無いような気もする。
0547デフォルトの名無しさん
2009/05/23(土) 19:39:320548デフォルトの名無しさん
2009/05/23(土) 19:39:360549デフォルトの名無しさん
2009/05/23(土) 19:43:50楽楽マルチインスタンス
継承はまああってもいいんじゃない？
0550デフォルトの名無しさん
2009/05/23(土) 20:21:51そんな構造にしてるやつはアフォ
そうしないといけない構造はこの世にない
0551デフォルトの名無しさん
2009/05/23(土) 20:47:41例外の話ではない。
> 結局node.valueを取得するまでmapをロック
> するコードを毎度クライアント側で書く必要がある。
あくまでそういう処理ならば、そう書くしかないのでは。
0552デフォルトの名無しさん
2009/05/23(土) 21:30:18その通り。だからノードを渡す、という動作は値を渡す、という
動作をそのまま置き換えるものではない、ということ。
ノードを渡すことによって確かに例外いらずになるかもしれない。
でも異なるものを渡す以上別のところで振る舞いが変わってくる
可能性もあって、例えばスレッドが絡んできた場合などがその一例
ということ。
0553デフォルトの名無しさん
2009/05/23(土) 21:48:44消えてなくなれー
0554デフォルトの名無しさん
2009/05/23(土) 21:50:050555デフォルトの名無しさん
2009/05/23(土) 21:54:010556デフォルトの名無しさん
2009/05/23(土) 21:58:33抽象は多くのものをひとくくりにする技術だから、
結局のところ多くの実体を仮定しているのと同じことなんだよ。
0557デフォルトの名無しさん
2009/05/23(土) 22:00:550558デフォルトの名無しさん
2009/05/23(土) 22:11:45データは現実の有り方のひとつの象徴だし、プログラムによる操作は、現実を象徴化した
モデルの操作なんだよ！
0559デフォルトの名無しさん
2009/05/23(土) 22:25:39どんなけメス会話してるんだよ...
0560デフォルトの名無しさん
2009/05/23(土) 22:30:28抽象だろうが馬鹿が
0561デフォルトの名無しさん
2009/05/23(土) 22:46:25余計な意味を加えて
これは抽象化、モデル化、象徴化なんだよ！
っていうのが怪しい。
0562デフォルトの名無しさん
2009/05/23(土) 22:47:33大差なくね？
というか一般層が考える抽象の意味よりは象徴の方がまだ意味が近い気がする。
まぁ真の意図は>>558に聞かんとわからんが
0563デフォルトの名無しさん
2009/05/23(土) 23:00:49学が無さ過ぎだろ。
抽象と象徴は日本語でも英語でも意味が違うし、具象と対をなす概念だ。
象徴の対義語は具象ではない。しっかり自分で調べてこい。
0564デフォルトの名無しさん
2009/05/23(土) 23:26:38一般層の話な。
0565デフォルトの名無しさん
2009/05/23(土) 23:32:06大抵、いい加減とかそういう意味に取られる。
いい加減自体の意味も厳密に言い出すとキリがないが…
0566デフォルトの名無しさん
2009/05/23(土) 23:38:43っていうか仕様どおりであってその辺の仕様があいまいなのを
プログラムに押し付けること自体すでに間違いだろ
何をいってるのかさっぱりわからない
頭悪いのにえらそうにしてるやつはずかしいから発言やめろ
0567デフォルトの名無しさん
2009/05/23(土) 23:46:14>まぁプログラマ以外に抽象を説明するときは困るな。
ちょっと理解しがたいシチュエーションだな。
>>564 の必死な弁解に付き合う必要はないと思うが。
0568デフォルトの名無しさん
2009/05/23(土) 23:53:16俺の会社だが
0569デフォルトの名無しさん
2009/05/24(日) 06:57:02> ハッシュとかの場合はノードそのものを返すようにするんだよ
毎回ノードをインスタンス生成しますか？
それともハッシュマップ中のノードをそのまま返して、
どっかのアフォがノードの中身を書き替えて、
滅茶苦茶トレースしにくいバグを作り込む元をつくりますか？
0570デフォルトの名無しさん
2009/05/24(日) 06:58:23longjumpは例外というより継続なのだが。
まあ継続で例外を実装することは可能だけど、
例外の元になったのがlongjumpかと言われると
それは間違いと答えるしかない。
0571デフォルトの名無しさん
2009/05/24(日) 10:31:21アクセスと切るまで他の人間はアクセス不能（もしくは読み取り専用）
っていうか仕様はどうなってるの？
0572デフォルトの名無しさん
2009/05/24(日) 10:40:010573デフォルトの名無しさん
2009/05/24(日) 10:41:57大抵は仕様が決まってないことが問題でオブジェクト指向とはなんの関係もないよね？
問題の切り分けもできない人が現場で報告もせずに勝手に騒ぎ立てるとか結構多い
0574デフォルトの名無しさん
2009/05/24(日) 11:29:32仕様を抽象的にすることは
両立できるのか？ という話だな。
まず厳密さだけ考えて、後でリファクタリングするとか。
0575デフォルトの名無しさん
2009/05/24(日) 12:16:21>いいわけに使うやつがいるけど
幸いにして、そこまでの莫迦は見たことがない。
>オブジェクト指向とはなんの関係もないよね？
肯。
■ このスレッドは過去ログ倉庫に格納されています