トップページ⇒tech
1001コメント306KB

消えてなくなれよ >オブジェクト指向 part.2

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2009/03/22(日) 06:57:59
前スレ
http://pc11.2ch.net/test/read.cgi/tech/1198822420/
0352デフォルトの名無しさん2009/05/20(水) 08:33:56
>>343
> 例外処理という名のGOTO文やシングルトンと呼ばれるグローバル変数を乱用し

Smalltalk否定ですか。
例外処理は例外がエスケープしなければ構造化を壊さないし、
Singletonを禁じ手にしたらSmalltalkのMetaclassをどう定義しますか？
0353デフォルトの名無しさん2009/05/20(水) 08:49:33
>>351
例外を嫌う理由がわからん。
メソッド呼び出しの深いところでエラーが発生したら、
いちいちエラー処理するレベルまで呼び出しを逆にたどって
エラーコードを戻すのってうっとしくないか？
0354デフォルトの名無しさん2009/05/20(水) 08:55:28
例外がどういうときに例外なのか作ったやつに聞いてみないとわからないのが嫌いだな俺は
大抵わかんねーし
馬鹿に限ってドキュメントかかねーし
普通にFALSE返せばいいようなのを例外で返ってくるようなのもあるしね
0355デフォルトの名無しさん2009/05/20(水) 12:11:24
>>353
それぞれの関数でエラー処理するだけだろ。
関数作るときに、それがどのくらいの深さで呼ばれてるとか
意識するべきではないし。
0356デフォルトの名無しさん2009/05/20(水) 12:36:07
ドキュメンテーションされていないと使い物にならない
のは例外も関数内でのエラー処理も一緒だと思うけど。
0357デフォルトの名無しさん2009/05/20(水) 12:42:54
コード＝ドキュメント
0358デフォルトの名無しさん2009/05/20(水) 12:44:03
>>355
エラー処理の実装を関数側に書きたくない事って多いと思うけど。
コンソールに吐きたいとかログに吐きたいとかダイアログ出したい
とか見ないふりして先に進みたいとか、呼び出し側で決めたいこと
は少なく無いと思う。

関数内で確保したリソースの解放とか、関数内で出来る後始末だけ
してもらって後はさっさと例外投げてもらった方が使い勝手が良い
し再利用性も高いと思うけど。
0359デフォルトの名無しさん2009/05/20(水) 12:47:56
メイヤーのオブジェクト指向入門の一冊目か二冊目にその話題なかった？
エラーを関数内で処理してしまうつくりは良くないとかなんとか。
0360デフォルトの名無しさん2009/05/20(水) 12:56:49
>>355
＞関数作るときに、それがどのくらいの深さで呼ばれてるとか
＞意識するべきではないし。

だから例外処理がいいんだろ。
それぞれの関数でエラー処理ってそらないわ、358の言うとおり。
03613552009/05/20(水) 15:01:11
エラー処理って、関数内で確保したリソースを開放して
エラーコード返すくらいだけど？
エラーコードをどう処理するかは呼び出し側の関数で決めればいいこと。
0362デフォルトの名無しさん2009/05/20(水) 15:42:34
>>361
355は直接呼び出したメソッドでエラー処理しているらしいことはわかった
おれは同じようなエラー処理をあちこちに書きたくないから例外を使う


0363デフォルトの名無しさん2009/05/20(水) 17:22:38
>>361
呼び出し関係が深くなっていった場合を考えよう。
それぞれの呼び出し側でエラーを認識して、そのまた呼び出し側にそのエラーを正しく伝えなければならない。
そんなことするぐらいなら、例外で1つのハンドラで包んだほうが構造として正しいと思わないか？
0364デフォルトの名無しさん2009/05/20(水) 20:08:53
>>328
Rubyってクラス指向でしょ。
クラスとインスタンスは明確に区別されている。
0365デフォルトの名無しさん2009/05/20(水) 21:24:47
そういうことじゃないだろう

C++はSimulaゆずりのクラス中心の言語なのに対して、
Rubyはインスタンス中心の言語にみえる。

もともとC++やSimulaは、抽象データ型言語であっても
オブジェクト指向言語とは言われてなかった。誰かが故意に
オブジェクト指向の意味を拡大解釈したんだろうね
>>313 のマルチパラダイム指向言語ならまだ許せる
0366デフォルトの名無しさん2009/05/20(水) 21:50:38
>>350
うほっScala知らなかったよ。禿が無断で削除した重要な機能が全部カムバックしとるw
関数はオブジェエクトだし、ジェネリクスはあるけどまともに型を認識する
C++のグチャグチャなエラー吐くマクロもどきはなくなってるじゃん
0367デフォルトの名無しさん2009/05/20(水) 21:54:52
>>365
365の言うインスタンス中心の言語って何だよ
おれはインスタンス指向といえばJavaScriptをイメージした。
C++とRubyは静的型付けか、動的型付けかの違い。
0368デフォルトの名無しさん2009/05/20(水) 22:34:34
>>363
俺は>>355とは違う人だけど
呼び出し側でそんなことする意味あんの？
仮に１００回その関数を記述したら１００箇所で同じ処理書くってことでしょ？
エラーはあくまで関数内で処理を決めるべきだと思う
そうしないと上記手間が増えるし、呼び出し側で正しいエラー対処をしないと・・・ってのがなんか気になる
だったら関数内でしかるべき処理しろよって思う

俺の理想は関数はあくまで成功したか失敗したかを呼び出し側に通知して
詳細なエラー処理はあくまでテメーでなんとかしろってのが俺流
もし、その関数の失敗の仕方が仕様に関わってくるならそれはもう
その関数は失敗していないんじゃないかと俺は思う（意味わかるかな？）
0369デフォルトの名無しさん2009/05/20(水) 22:44:15
>>367
C++はまずクラスを作りそれを型紙としてインスタンスを生成する
Rubyはまずインスタンスを作りメンバーを追加する
書式を似せて同じように見せているが中身が全く違う
Rubyのクラスというのはデフォルト実装の指定であって
動的型付け言語というより型の無い言語と考えるべき
C++に後からメンバ関数を追加する簡単な方法はない
0370デフォルトの名無しさん2009/05/20(水) 23:11:16
Pythonはどっちに似てる？
0371デフォルトの名無しさん2009/05/20(水) 23:29:19
>>368
俺は>>363とは違う人だけど

＞呼び出し側でそんなことする意味あんの？
そんなこっとってエラー処理だよね

＞呼び出し側に通知して
＞詳細なエラー処理はあくまでテメーでなんとかしろって
これって呼び出し側でエラー処理しろってことだよね

言ってることがよくわからん。
0372デフォルトの名無しさん2009/05/20(水) 23:54:37
>>371
違うってだから例外で色々キャッチさせるだろ？
こっちが例外を全部処理しなきゃいけないみたいによ
でも実際に必要なのは

BOOL transXXXX()

これ↑このBOOLだけじゃん
詳細な情報ってのは関数の中でやればいいじゃん
（だって決まったエラー対応してほしいんでしょ？）
0373デフォルトの名無しさん2009/05/21(木) 00:09:55
>>367
簡単に言うと、RubyではクラスCのインスタンスaとbがあったとして、aにのみ実行中にメソッド（メンバ関数）を追加できる。
Javascriptと同様にインスタンス指向の言語と呼べると思う。
0374デフォルトの名無しさん2009/05/21(木) 00:14:28
>>372
関数内でエラーが発生したら戻り値をfalseにするというのはわかった。
例えば通信用の送信関数でBOOL SendMessage(string message);
て感じのものがあって、呼び出し側SetupDeviceは何回かSendMessageを呼ぶとする
エラーリターンの場合は
int SetupDevice() {
if (!SendMessage("Init")) return false;
if (!SendMessage("Set1")) return false;
if (!SendMessage("Set2")) return false;
return true
}
void main() {
if (!SetupDevice()) printf("通信エラー");
//後続処理
}
0375デフォルトの名無しさん2009/05/21(木) 00:14:44
>>337
わざとなのかもしれんが意味不明で滑ってる
0376デフォルトの名無しさん2009/05/21(木) 00:18:18
つづき、例外なら
void SetupDevice() {
SendMessage("Init");
SendMessage("Set1");
SendMessage("Set2");
}
void main() {
try {
SetupDevice();
//後続処理
} catch() { //通信の例外が発生
printf("通信エラー");
}
}
で、楽だと思う
0377デフォルトの名無しさん2009/05/21(木) 00:19:55
>>372
詳細な対応をしたいときはどうする？
0378デフォルトの名無しさん2009/05/21(木) 00:22:56
>>377
ありえない（俺の経験上）
それは結局他の呼び出し箇所でもやらなければいけない内容であって
関数の中でやれと思う
0379デフォルトの名無しさん2009/05/21(木) 00:24:26
オブジェクト指向の言語だからと、例外を使う必要は必ずしもないということか。
0380デフォルトの名無しさん2009/05/21(木) 00:25:00
さらにもし、この関数がステータスを返してそのステータスの内容によって
処理を変えることが必要であるなら
そもそもこの関数はfalseを返してはいけない
この関数がfalseを返すときは出力のすべてが無効のときでなければならない・・・はず
0381デフォルトの名無しさん2009/05/21(木) 00:27:43
>>373
了解、特異メソッドはインスタンス指向だと思う
objectのインスタンスに特異メソッドを追加するだけの方法で
プログラミングできるとも思う。

自分はあまり特異メソッドを使っていない。
クラス指向で組んでいる。

rubyはどちらにもなると言うことか
0382デフォルトの名無しさん2009/05/21(木) 00:27:53
>>376
SetupDeviceが例外を吐いてくれるかどうかはそのソースのどこで判断するの？
後続処理のどれかが吐いてる例外かもしれないんでしょ？
0383デフォルトの名無しさん2009/05/21(木) 00:41:17
>>382
だから後続処理で通信エラーが発生しても例外処理が1つで済むんだよ
SetupDeviceだけ通信エラーをトラップしたいなら
void SetupDevice()
{
0384デフォルトの名無しさん2009/05/21(木) 00:43:27
>>383
そんなこと聞いてないよ
初見でみた人がSetupDeviceが例外を返す仕様かどうかをどうやって判断するか聞いてるんだよ
0385デフォルトの名無しさん2009/05/21(木) 00:46:39
途中で送信してもた
だから後続処理で通信エラーが発生しても例外処理が1つで済むんだよ
そんなニーズはあまりないが、あえてSetupDeviceだけ通信エラーをトラップしたいなら
例外処理をmainからSetupDeviceに移して
void SetupDevice()
{
ｔry {
SendMessage("Init");
SendMessage("Set1");
SendMessage("Set2");
} catch() { //通信エラー
printf("通信エラー");
}
}
0386デフォルトの名無しさん2009/05/21(木) 00:47:59
>>385
さっきから勝手に質問を曲解してうぜぇけど
誰もそんなこと聞いてねぇよ
0387デフォルトの名無しさん2009/05/21(木) 00:49:37
>>384
ドキュメント
0388デフォルトの名無しさん2009/05/21(木) 00:52:43
>>387
アフォだな
確実にセンスのねぇクラスとメソッドだな

if(!SetupDevice()){
　//エラー
}

こう書いてあったほうが何倍も読みやすいじゃねーか
例外かいて仮にこれが省略できたとしても
この仕様でソース書き続けたらクラス使ってあるたびに
元のソースかドキュメント確認して例外かえすかどうか確認しなくちゃいけないんだぞ
超面倒くせぇセンスねぇ時間ばかり使ってぇなにも産まねぇｗ
0389デフォルトの名無しさん2009/05/21(木) 00:58:21
>>383
初見でみた人がSetupDeviceの戻り値が成否を返す仕様かどうかをどうやって判断する？
0390デフォルトの名無しさん2009/05/21(木) 00:59:22
>>388
Win32APIってそういう形式だよね
0391デフォルトの名無しさん2009/05/21(木) 01:02:34
>>390
成功のときが0で失敗のときがエラーコードのときもあるから
結局仕様を確認しないといけないから手間かかるけどな。
あげくにBOOL型を返しつつ
BOOLの中身が0と負数と正数の三種類の値を返すときもあるから
型も信用できない
0392デフォルトの名無しさん2009/05/21(木) 01:17:50
>>388
俺もそのスタイルの方が、だんぜんにエラー処理がやりやすい。

結局、マジメにエラー処理をしたいかどうか、の違いだと思う。
例外ってエラー処理をマジメにやらないで済ませるためのものなんだよね。
エラー時の処理が全部同じならまとめてしまえ、っというのが例外の狙い。

だから、例外の種別ごとに処理しよう、とかマジメにやろうとすると
基本設計と矛盾しちゃうのでかえって分けの分からないことになってしまう
0393デフォルトの名無しさん2009/05/21(木) 01:32:02
>>389
普通、関数のコメントに書くだろ。doxgen形式か何かで。
0394デフォルトの名無しさん2009/05/21(木) 01:33:32
>>393
どういう例外を投げるかの仕様もまた同じことだろうね。
0395デフォルトの名無しさん2009/05/21(木) 01:39:31
このスレは結構勉強になりますね
0396デフォルトの名無しさん2009/05/21(木) 01:39:43
SetupDeviceでは例外をthrowしていないばあいでも、
SetupDeviceが使っているSendMessageが呼び出す関数が例外を投げるように
なるかもしれないというのはある。
0397デフォルトの名無しさん2009/05/21(木) 03:44:54
返値がnullだったり-1だったりEOFだったりしたらエラーかも
しれない、なんて一種の暗黙知というか風習の類。

そうではない場合も少なからずあるし、結局例外にせよ返値に
せよ、どちらもドキュメントやコメント読まないと意味がない。

ただ言語によって異なるけどJavaなんかだと文法的に例外処理を
強制しているので、どのような例外が投げられるか把握して
いないとそもそもコンパイルが通らない。
なので最低限メソッドがどんな例外クラスを投げるかの情報は
コンパイラのエラー出力を読めば分かるし、メソッドのシグネチャ
にも明記してある点では分かりやすい。
0398デフォルトの名無しさん2009/05/21(木) 03:50:01
>>391
>成功のときが0で失敗のときがエラーコードのときもあるから

横だが
俺いつもそれで困る。

0がエラーだったら
if（!DoHoge()）の！がびっくりした感じでなんとなくエラーっぽい外観でわかりやすいんだけど
この表記が成功だったり失敗だったりで紛らわしい。
同じ関数内で混在すると特に。

0が成功だと
if(DoFoo())のあとにエラー処理書くのがなんとなく気持ち悪い。

>>388の例みたいに
//エラー処理
って冒頭に書けばいいだけかもしれんけど
0399デフォルトの名無しさん2009/05/21(木) 04:12:43
>>388
SetupDeviceがSetupDevice1を、SetupDevice1がSetupDevice2を、と深く呼び出していって、
SetupDevice10が実際にデバイスとIOしているとしよう。

おまえの書き方だと、SetupDevice1からSetupDevice9の定義は
int SetupDevice1(void) {
　　code =SetupDevice2()
　　if (code) {
　　　　do_other_initialization1();
　　}
　　return code;
}
みたいになって、9箇所でエラー処理部分と正常処理部分を切り分けなきゃならない。
そして、どのレベルでどのようなエラー回復がされるのかが見えなくなる。

例外処理を使ってかけば、エラー処理は実際にハンドラを定義している部分だけで
余計なif (code)は不要になるし、ハンドリングしている箇所を追いかけるのも、
IDEがちゃんとしていれば指定された例外をハンドラ定義している部分を簡単に見つけられる。
if (code)では一般のif文だからそうはいかない。1つ1つ関数を読んで確認しなければならない。
0400デフォルトの名無しさん2009/05/21(木) 06:06:21
>>399
つ longjmp

てのはおいておいて、状況によるんじゃないの?

何らかの言語のソースをパースしているときの EOF の扱いとかだと,
EOF を読み出す状況(ソース中の位置に)よって対応が変化するので
try {
if ((token = read_token(...)) == EOF) {
eof の処理
}
} catch (io_error e) {
エラーの処理
}
の, 形で書けた方が直感的.
java みたく EOFException で返されるとソース読みにくい
慣れの問題なのかも知れないが...
0401デフォルトの名無しさん2009/05/21(木) 06:10:27
>>399
はぁ？何を心配してるのかさっぱりわからない
SetupDeviceの中身なんて関係ねーんだよ
呼び出し側優先で考えて作ってくれよ
0402デフォルトの名無しさん2009/05/21(木) 07:32:50
>>396
それ最悪だよね
マジでなにを確認したらいいのかわからなくなる
SetupDeviceの仕様もドキュメントも変わってないのにある日突然よくわからないタイミングで例外降ってくるよね
0403デフォルトの名無しさん2009/05/21(木) 07:34:23
エラーコードだけで対応するんじゃなくて例外使った方が柔軟に対応できると思う
0404デフォルトの名無しさん2009/05/21(木) 07:35:52
>>399
下手な書き方だな。
0405デフォルトの名無しさん2009/05/21(木) 07:50:06
関数内でエラー処理を一ヶ所にまとめるために例外を使うことはあっても、
関数の外に例外を投げることは極力やらないようにしてる。

関数外に例外を投げるのは、例外を出す関数と例外を処理する関数が密接に関連してて、
どういうケースでどういう例外が出て、どう処理すればいいのかをそれらの関数全体で
設計するときくらいかな。
0406デフォルトの名無しさん2009/05/21(木) 07:57:31
ときくらいかな
じゃなくてそんなことしないほうがいいんじゃないの？
04074052009/05/21(木) 08:04:58
そういう設計したほうがエラー処理がスマートになるときだけ。
0408デフォルトの名無しさん2009/05/21(木) 08:22:01
mainでは例外が発生したら例外オブジェクトが持っているメッセージを表示するだけ。
それでは済まない場合、例えばデータベースの処理でロールバックしなきゃいけないなど、
そんなときだけ途中レベルで例外処理して、例外を再送出している。

例外使っててドキュメントが増えて難儀するなんてことはない。

>>402
396のSendMessageが呼び出す関数で例外が発生するようになるというのは仕様変更
関数の仕様変更に呼び出し側が対応するのは例外・エラーリターンどちらでも同じ
0409デフォルトの名無しさん2009/05/21(木) 08:25:48
これぐらいのレベル（エラーが起きたら終わっちゃえ）ぐらいの
志しでいい場合は例外でもいいかもね
0410デフォルトの名無しさん2009/05/21(木) 08:32:31
>>409
エラー起きても終わらせたくないときは途中レベルで例外処理
エラー処理を荒くもできるし細かくもできる
0411デフォルトの名無しさん2009/05/21(木) 08:34:42
失敗するかもしれない関数の返値で今一番かっこいいのは、
ScalaのOption、HaskellのMaybeみたいな奴だろ。C#のNullableも近い。
0412デフォルトの名無しさん2009/05/21(木) 08:35:39
>>408
それは、エラーハンドリングしなくていいプログラムの場合だろ？
SendMessageのような通信もののばあい、エラーが起きたらそのコマンド
再送するけど、数回繰り返してだめだったら最初からリトライする。
というようなわりとめんどうなエラーハンドリングしないといけないことがおおい。
0413デフォルトの名無しさん2009/05/21(木) 09:02:45
この人たちは、なんで「例外処理は場合による」って言い合ってるの?
お互いに、「そうじゃない、例外処理は場合による」なんて言ってたらまとまる訳無いじゃん
0414デフォルトの名無しさん2009/05/21(木) 09:07:51
>>413
前提の整理がされてないから当然の流れ
0415デフォルトの名無しさん2009/05/21(木) 09:49:36
>>369
「インスタンスを作って」って言ってるけどさ、処理の内容はソースで書くじゃない
動的な配列の確保と違って、その場限りって事は無いだろ
0416デフォルトの名無しさん2009/05/21(木) 09:59:50
なんだかんだ言ってもオブジェクト指向の意味がよーわからんよ。
0417デフォルトの名無しさん2009/05/21(木) 10:09:35
誰も解ってないから大丈夫。
0418デフォルトの名無しさん2009/05/21(木) 10:11:35
今日本で1番わかっているOOの権威って誰だろ？
0419デフォルトの名無しさん2009/05/21(木) 10:32:58
ほとんどの言語で例外は非常にコストの高い処理、ということは知ってる？
俺は、プログラムが異常終了しないようにする保険みたいなものと考えてるけど
0420デフォルトの名無しさん2009/05/21(木) 12:24:50
例外はメリットないな
0421デフォルトの名無しさん2009/05/21(木) 15:23:45
標準入出力にstdoutとstderrの二つがあるように、関数呼び出しの
結果を戻す方法に返値と例外の2ラインがあるだけでも使い勝手が
あると思うけど。

例えば正常な返値としてnull等々も返しうる関数で、しかも時には
エラーも返したい、という場合はどう書くのかな。
0422デフォルトの名無しさん2009/05/21(木) 17:47:16
>>401
> SetupDeviceの中身なんて関係ねーんだよ
> 呼び出し側優先で考えて作ってくれよ

>>399の例で言えば
SetupDevice1からSetupDevice9まで
全部「呼び出し側」なことに気付けカス
0423デフォルトの名無しさん2009/05/21(木) 17:49:18
>>421
例外を投げるように作っておけば、
エラーコードを返すほうのバージョンは簡単にラッパーで書ける。
0424デフォルトの名無しさん2009/05/21(木) 17:56:56
>>422
はぁ？
なんで関数の中までみないといけないの？
この時点でおかしいじゃん
馬鹿なんじゃない？
0425デフォルトの名無しさん2009/05/21(木) 18:00:57
メソッドチェーンして使うような関数のエラーは例外で返して
ほしいかなぁ。
チェーンの途中でnullとか出力されるとヌルポが怖くて使えん。
0426デフォルトの名無しさん2009/05/21(木) 18:20:06
>>422
>>424は関数の内部の実装なんか知ったこっちゃねぇ、ただ
APIとしてユーザに公開される関数に関しては例外を投げるな、
エラーコードで戻せ、と言いたいんじゃ無いのかな。

気持ちとしては分からないでもない。
でもどちらが良いかは実際の関数の使われ方によるんじゃないのかな。
例外で投げてもらった方が使い勝手が良い場合もあるし。
0427デフォルトの名無しさん2009/05/21(木) 19:22:45
>>426
使われ方？はぁ？
言葉に気をつけろよ
１回潜ったら１００回潜っていく必要があることと等価だろ？
関数が呼んでる関数の中で呼んでる関数の仕様に翻弄されてちゃ
いつまでたっても完成なんかしないよ
0428デフォルトの名無しさん2009/05/21(木) 19:51:42
そもそも例外ハンドルだらけのソースになって、美しくないんだよね
Javaもその点が残念すぎる
0429デフォルトの名無しさん2009/05/21(木) 20:40:57
>425
ヌルポも立派な例外だろ。
0430デフォルトの名無しさん2009/05/21(木) 23:10:09
>>419
例外処理は重いというのは良くみるけれど、今ひとつぴんとこない。
従来の関数の戻り値を見るやり方に比べて重いのは、例外発生時に例外オブジェクトを
newするという点だけだと思うんだけど間違ってる?
0431デフォルトの名無しさん2009/05/21(木) 23:26:51
例外の速度なんて気にしてるのキチガイだろ
かまうな
レスをつけるな
0432デフォルトの名無しさん2009/05/21(木) 23:33:35
富豪的
0433デフォルトの名無しさん2009/05/21(木) 23:46:16
例外って局所的なエラーチェックに用いるものじゃないでしょ
拾い溢しを防ぐような使い方がいい

先にアプリケーションがあって、ライブラリが後から実装みたいな開発の仕方なら
例外中心のほうがいいけど
0434デフォルトの名無しさん2009/05/22(金) 00:00:11
>>430
Javaの場合スタックトレース（呼び出し階層）を生成するから遅いよ。

復帰可能かつ精度が求められない演算（たとえばストリーミングで動画再生とか）での
エラー処理って言うのは、わざわざスタックトレース生成せずにそのブロックだけ
空の値を返すとか前回の演算結果をそのまま返すとかしたほうがいい。

結局はエラー処理をどう扱うかなんてケースバイケースなんだけど、
そのケースの要件とか許容範囲を精査せずに実装すると切ないことになる。
0435デフォルトの名無しさん2009/05/22(金) 00:11:19
>>434
誰もそんなこと聞いてねぇよ
消えろよ馬鹿
0436デフォルトの名無しさん2009/05/22(金) 00:14:48
いつの間にか「消えてなくなれよ＞例外処理」になってるｗｗｗ
0437デフォルトの名無しさん2009/05/22(金) 00:42:47
>>432
時代遅れ
0438デフォルトの名無しさん2009/05/22(金) 00:46:13
人間の負荷を1番気にしてください　＞＜
0439デフォルトの名無しさん2009/05/22(金) 05:26:49
結局、例外ハンドラを設定し忘れてバグ出したクズPGが
自分の失敗を例外処理のせいにしてヤツアタリしている、

ということで了解。
0440デフォルトの名無しさん2009/05/22(金) 06:15:39
>>439
は？
日本語読めないクズは黙ってろよ
0441デフォルトの名無しさん2009/05/22(金) 06:18:58
>>388でＦＡ
0442デフォルトの名無しさん2009/05/22(金) 07:20:25
だな
0443デフォルトの名無しさん2009/05/22(金) 07:47:06
>>388
アフォだねえ

> if(!SetupDevice()){
> 　//エラー
> }

エラーは一種類しかないのかいw

> この仕様でソース書き続けたらクラス使ってあるたびに
> 元のソースかドキュメント確認して例外かえすかどうか確認しなくちゃいけないんだぞ

どんなポンコツIDE使ってんだよ。
どのメソッドがどんな例外をthrowするかなんてIDEがチェックできるだろ。
そのためのthrows句だ、カス。

そもそも、エラー返す場合のほうがどの関数がどんなエラーコードを返すか、
元のソースかドキュメント確認しなきゃならないだろ。

> 超面倒くせぇセンスねぇ時間ばかり使ってぇなにも産まねぇｗ

その言葉、そっくり
> if(!SetupDevice()){
> 　//エラー
> }
こういうアフォなことやる底辺PGに返してやるよ。
0444デフォルトの名無しさん2009/05/22(金) 07:55:16
388に賛同する香具師って、ロクにエラーチェックもせずに垂れ流してるデジドカなんじゃね？
0445デフォルトの名無しさん2009/05/22(金) 08:06:05
例外使う派だが
JavaのEOFや、VB6のCollectionのキーのない要素にアクセスしたときの例外は
例外の乱用だと思う。
0446デフォルトの名無しさん2009/05/22(金) 08:06:12
>>388に賛同する奴は例外を使ったことないんだろうな
0447デフォルトの名無しさん2009/05/22(金) 08:35:46
>>445
下手にNullなんぞ返されるより、例外を上げてもらったほうがナンボかマシだなあ。
0448デフォルトの名無しさん2009/05/22(金) 08:36:19
>>443
一連のレスを読めばその辺の返答は全部書いてあるんだけど？
0449デフォルトの名無しさん2009/05/22(金) 08:41:07
>>448
そのことごとくが的外れであることが指摘されているわけだが？
0450デフォルトの名無しさん2009/05/22(金) 08:50:36
一方は、「例外を使う必要が無いところで例外を使うな」
一方は、「例外を使う必要が有るところで例外を使おう」

お前ら馬鹿だろ?
0451デフォルトの名無しさん2009/05/22(金) 08:53:24
プログラマに1番大切なのは日本語コミュ力だというのは良く分かった。
0452デフォルトの名無しさん2009/05/22(金) 08:57:15
あえて普及しているオブジェクト指向を見直すのがこのスレなんだし
例外についても見直せて良かったんじゃない？

やっぱりおれは例外使うけど
■ このスレッドは過去ログ倉庫に格納されています