2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

例外を正しく使えないプログラマ多いね。 その6

1 :仕様書無しさん:2011/02/19(土) 05:04:31
前スレ

例外を正しく使えないプログラマ多いね。 その5
http://hibari.2ch.net/test/read.cgi/prog/1296976411/

2 :仕様書無しさん:2011/02/19(土) 05:07:50
例外のおかしな使い方を見つけたら張るとか
こういう使い方してるの見たけど、こっちのほうがよくね?とか

そういう話題は例外的で、基本脱線議論を行う
ここはきっとそんなスレッドです

3 :仕様書無しさん:2011/02/19(土) 07:19:21
try{
  スレッドSercice.post>>1乙(thisThread);
} catch (糞スレException e) {
  京大霊長類研究所Service.callアイちゃん(thisThread);
}

4 :仕様書無しさん:2011/02/19(土) 08:14:26
早朝にスレ立てとか。 オマエ、学生か無職だろw

構って欲しくて仕方が無いんだな。

5 :仕様書無しさん:2011/02/19(土) 08:28:15
例外が発生しました
クラスUnexpectedException。場所>>4。内容:曜日感覚がありません

6 :仕様書無しさん:2011/02/19(土) 08:37:27
関数から戻り値はクリーンな値でなければならない。
もらった値はすぐに次の処理で使用できるべき。
つまり値として不正な物が含まれていてはいけない。



7 :仕様書無しさん:2011/02/19(土) 08:40:23
今日に限らないから言ってんだけどねw

8 :仕様書無しさん:2011/02/19(土) 09:17:14
一人のバカが遊ばれてるスレ

9 :仕様書無しさん:2011/02/19(土) 10:45:38
>>6
何を重視するかは文化で変わる。
つ tryParse

10 :仕様書無しさん:2011/02/19(土) 10:55:44
>>9
それは文化じゃなくて関数の仕様。
関数名が、parseではなくtryParseとなっていることに注意

その関数はparseするのではなく、tryする関数。
だからtryした戻り値はtryした結果になる。

tryParseの戻り値は、parseした結果が含まれることはなく、
tryした結果、つまり変換できるかできないかが返る。

やってはいけないのは、関数の戻り値に、値とエラーコードが混ざること。
tryParseは混ざってない。

11 :仕様書無しさん:2011/02/19(土) 10:55:57
文字列を数値に変換するのに失敗したみたいな、作る時から予測可能なことで
いちいち例外処理させられるのは、無駄に長くてコードが見づらい

文字列を数値に変換できるか調べるメソッドを事前に呼べってことなのかもしれないが

12 :仕様書無しさん:2011/02/19(土) 11:00:26
>>11
例外を出したくないのなら、例外を出さなくていいんだよ。
tryParseみたいに、try○○って関数を作ればいい。
ただ戻り値に値とエラーコードを混ぜてはだめ。

だからといって、すべての関数にたいして
try○○をつくろうと思うなよw

スタックトレースの出力とか例外のほうが優れているんだし、
使うのは必要最小限にしとけ。

13 :仕様書無しさん:2011/02/19(土) 11:03:16
関数の戻り値に値とエラーコードを混ぜないというのは、

int errorcode = func(param, &out_value);

もしくは、

int value = func(param, &out_errorcode);

のどちらかの形式を使えということ
tryParseはこれに従っている。

int value_or_errorcode = func(param);

これはいけない。変数名からしていやだろ?

14 :仕様書無しさん:2011/02/19(土) 11:35:46
例外はGOTO文と同じ。
tryの位置で割り込み例外が起きたら、ここへ飛べと書いているだけ。
GOTO文を多用するプログラマーは馬鹿だ。

例外が起きたら、やることは2つ「リカバリーとリソース保護」だ。
それ以外の処理を書く奴はアホだ。

15 :仕様書無しさん:2011/02/19(土) 11:40:49
>>14
例外とgotoはぜんぜん違う。

例外はエラー処理にしか使わない。
gotoと違って前の処理に戻らない。

gotoをエラー処理になら利用しても良いという考えに
したがって作られたものと言える。

16 :仕様書無しさん:2011/02/19(土) 11:40:52
.NETのTryParseはParse結果もセットしてくれるけどな。
戻り値はtry結果だけど。

17 :仕様書無しさん:2011/02/19(土) 11:43:08
>>16
parse結果とtry結果を混ぜてないからOK

18 :仕様書無しさん:2011/02/19(土) 11:50:25
何を長々と語っとるんだこのアホは

19 :仕様書無しさん:2011/02/19(土) 11:52:03
お前も語ることがあるなら語っていいんだよ。
反論がないと面白くないw

20 :仕様書無しさん:2011/02/19(土) 11:56:11
>>14
gotoは飛ぶ瞬間が明示的なのに対して
例外はなんの記述もないのに吹っ飛んでくるから俺は例外のが嫌い

21 :仕様書無しさん:2011/02/19(土) 11:57:15
>>20
throwすればいいじゃん?

22 :仕様書無しさん:2011/02/19(土) 12:01:45
gotoは絶対悪なんじゃなくてそれこそ
「gotoを正しく使えないプログラマ多いね」って状態になりやすいから原則禁止にして、
よく使うパターンに関してはbreakやcontinueのような専用の命令を導入してる。

23 :仕様書無しさん:2011/02/19(土) 12:03:30
そのbreakとcontinueでもやれないこと、
つまりエラー処理のためのgotoの代わりになる
専用の命令が例外なんだ。

24 :仕様書無しさん:2011/02/19(土) 12:07:13
例外を備えることによって、
本当にgotoをなくすことに成功したよな。

25 :仕様書無しさん:2011/02/19(土) 12:10:27

if(!checkXXX()){
  MessageBox("XXXXXX");
  return false;
}

的処理がgoto使っちゃうと

if(!checkXXX()){
  goto ERROR;
}
 ・
 ・
 ・

ERROR:
  MessageBox("XXXXXX");
  return false;

みたいに分離して
初っ端の記述が多少楽になるだけであとの保守が超面倒臭い
しかも途中で増えたら増築方法が

ERROR:
  MessageBox("XXXXXX");
  return false;

//new!
ERROR2:
  return false;

みたいにカオスな追加方法になるのも嫌い、例外も似てるから同様に嫌い

26 :仕様書無しさん:2011/02/19(土) 12:14:20
993 :仕様書無しさん:2011/02/19(土) 01:03:05
なんか具体的な例がないからいかんのだな
例外化の学習
テーマ「メソッドの設計」
言語、C,C++,Java,C#に限定しようか
Cでは例外は機能として無いからsignalでも関数ポインタのコールバックでもなんでもいいよ。シンプルで合理的な仕様を考えよう。

仕様概要
HTML formタグのnameパラメータを動的に入れ替えるメソッドを作成する


<input type="text" name="NAME_HOGE" size="43">
メソッドを実行すると
<input type="text" name="REIGAI_SUKINA_AHO" size="43">
のようにname=の後の文字列が変更される仕様

クラス名: 自由につけろ(Cはいらない)
メソッド(関数名): 自由につけろ
メソッド(関数)の型: 自由に考えろ
メソッドに渡す引数: 自由に考えろ
おこりうるエラーと捕獲するべき例外:自由に考えろ

さあ作ってみろ。馬鹿どもよ。
なんだよ、誰も擬似コードすら書けないのかよ、んとに馬鹿ぞろいだな

27 :仕様書無しさん:2011/02/19(土) 12:17:25
>>25
if(!checkXXX()){
  msg = "うんこがもれそうです";
  flg = FALSE;
  goto ERROR;
}
 ・

done:
  if(!flg) MessageBox(msg);
  return flg;

こうすりゃあいいだろう、お前馬鹿だな

28 :仕様書無しさん:2011/02/19(土) 12:18:40
>>25
例外の場合は、処理を飛ばすだけじゃなくてオブジェクトを渡せる。

だから
if(!checkXXX()){
  MessageBox("XXXXXX");
  return false;
}



try {
  checkXXX();
} catch(Exception e) {
  throw new MyException("XXXXXX", e);
}

こうなる。そしてこのようなことができる。
try {

} catch(MyException e) {
  MessageBox(e.getMessage);
  printlog(e)
}


29 :仕様書無しさん:2011/02/19(土) 12:19:56
goto ERROR; ->goto done; なスマソ

30 :28:2011/02/19(土) 12:20:56
こうすることで、ユーザーインターフェース部分(メッセージボックス)を
処理と分離することが可能で、もしこれがコンソールなら簡単にprintfに置き換えられるだろう。

また、スタックトレース(関数の呼出履歴やエラーが発生した行番号)を
ログファイルに出力することもできる。
これは、例外を使わない場合は自分で作りこまなければわからない情報。


31 :仕様書無しさん:2011/02/19(土) 12:21:40
>>30
うえせえよ、おじゃば!!

32 :仕様書無しさん:2011/02/19(土) 12:23:10
うえせえなぁw

33 :仕様書無しさん:2011/02/19(土) 12:24:07
>>32
お前、どうせ言い回しで於邪婆ってわかるんだからコテつけろw

34 :仕様書無しさん:2011/02/19(土) 12:24:53
わかるならコテいらないよ。

35 :仕様書無しさん:2011/02/19(土) 12:26:34
おじゃばさまとは (unkopedia)

かつて69式オッサンスレとかで、その人柄とダサイ思考回路が大人気だった
人です

36 :おじゃば ◆hMIVgvHpWk :2011/02/19(土) 12:29:55
>>33
ほらよ。コテつけた。これで満足だろ?
コテついてるのが、おじゃばだ。

37 :仕様書無しさん:2011/02/19(土) 12:30:03
しっかし、相変わらずくどくどしいコード書いてからに・・・
スキルが全くあがってないのはある意味おじゃばらしいな

38 :仕様書無しさん:2011/02/19(土) 12:30:53
つーことで、コテ付いてない俺は
おじゃばじゃないということですね

39 :仕様書無しさん:2011/02/19(土) 12:31:15
それと、相変わらず「業務システム」に特化しているようだなw

40 :仕様書無しさん:2011/02/19(土) 12:31:40
わざと非常識な事を言って、屁理屈付けて他人をからかってんのか。

しょーもないやっちゃな

41 :仕様書無しさん:2011/02/19(土) 12:32:49
真のおじゃばは 「おじゃばさま」のみで◆トリップはなしだ

42 :仕様書無しさん:2011/02/19(土) 12:32:53
>>39
そうか?

俺は基本的にウェブシステムの話をしてるんだが。

43 :仕様書無しさん:2011/02/19(土) 12:33:40
>>42 MessageBoxを出すWebシステムですか? 革新的ですなあ

44 :仕様書無しさん:2011/02/19(土) 12:34:26
>>43
MessageBoxは>>25に言えよ。
くどくどしいコード書いた>>25に合わせただけだろ。

それぐらいさぁ、言わなくても分かんないか?

45 :仕様書無しさん:2011/02/19(土) 12:35:15
>>44>>25も俺からみると五十歩百歩だからわからんなあ、すまんな

46 :仕様書無しさん:2011/02/19(土) 12:37:10
>>45
あなたは150歩ぐらいですか?

47 :仕様書無しさん:2011/02/19(土) 12:37:52
そうか、>>25が戻り値(0div君)で
偽おじゃばが>>44か。よしわかった
それよりも >>26を完璧なコンパイルコードでなくともいいから
設計してみてくれよ、例外を利用する前提でさ

48 :仕様書無しさん:2011/02/19(土) 12:38:20
もしかして、「はつみみです」の人?

49 :仕様書無しさん:2011/02/19(土) 12:40:23
>>47
サンプルで例外も戻り値エラーも書いてないコード書いてくれよ。

お前が聞きたいことの本質はエラーをどうするかだろ?
お前が聞きたいことと関係ないコードを書くのは面倒だ。

50 :仕様書無しさん:2011/02/19(土) 12:42:09
>>49 だから不要な箇所は省いていいよ。
俺がサンプル出したら設計にならないだろう
繰り返して言うけど、省くとこは省いても良い、完全なコンパイルコードで
無くとも良い、擬似コードレベルでも良い
それを見ると君のレベルが分かるからさ

51 :仕様書無しさん:2011/02/19(土) 12:42:50
>>28
例外にエンドユーザに見せるための文字列を入れるのはクソ設計

52 :仕様書無しさん:2011/02/19(土) 12:44:39
>>51
そうねえ、MessageBoxでなくてシステムログに静かに記録するのがベターかな

53 :仕様書無しさん:2011/02/19(土) 12:48:16
>>50
じゃあ実際にHTMLを解釈するコードは不要だな。

$('input[name="NAME_HOGE"]').name = "REIGAI_SUKINA_AHO";

以上。

あ?言語の指定があったな。 JQueryを使ったJavaScriptコードはだめか?

document.getElementsBySelector("input[name=\"NAME_HOGE\"]").setName("REIGAI_SUKINA_AHO");

以上。

起こりうる例外は、セレクタ文法のエラーとか、
詳しくはJQueryのドキュメント見てくれ。
どうせ俺が書いてもコピペするだけだから。

54 :仕様書無しさん:2011/02/19(土) 12:49:52
>>51

それは>>25にいえや。
なんで俺にだけ言うんだよ。

それにじゃあ、どう対処するかなんて
一瞬で思いつくことだろ。

55 :仕様書無しさん:2011/02/19(土) 12:53:41
>>53
ぐはははははは、やっぱりそうきたか。
俺が示して欲しいのは文字列操作時に発生する問題をきちんとトラップした
設計だよ。あの設問からプロシステム屋ならば「なにが大事か」をすぐに分かるはず
だけどね。複数発生する例外をどう設計対応するかが大事。
せっかく作ってくれたけど、ほんとコードでなくてもいいし
考えられる「発生する例外の種類」を列挙してくれないかなあ

56 :仕様書無しさん:2011/02/19(土) 12:59:08
>>55
つまりどういうこと?

57 :仕様書無しさん:2011/02/19(土) 13:00:24
>>55
もう少し人に分かるように言えよ。

そのお前の言い方だとな、
戻り値使う方も、何も応えられないよ。

例外を使う場合はちゃんと示したのに、
戻り値エラー派は実際に何も答えてないしね。


58 :仕様書無しさん:2011/02/19(土) 13:06:24
さて、気が狂ったアホは放っておいて、
例外と戻り値の話に戻ると、先の

$('input[name="NAME_HOGE"]').name = "REIGAI_SUKINA_AHO";

これ。凄くシンプルだけど、これ戻り値をエラー返す方式では使えないんだ。

なぜなら、$()関数 が戻り値をエラーで返すと、
[見つかった複数のエレメントオブジェクト].name = "REIGAI_SUKINA_AHO";
ではなく、

[エラー値オブジェクト].name = "REIGAI_SUKINA_AHO";
となってしまう。

この場合、全く意図しない動きになってしまうのはわかるよね?
例外が優れているのはこういう所。

59 :仕様書無しさん:2011/02/19(土) 13:08:39
例外処理中でメッセージボックス表示しちゃダメだって言うなら、
いつのタイミングで表示すればいいのさ?

60 :仕様書無しさん:2011/02/19(土) 13:10:22
>>59
そりゃ、ユーザーインターフェース層じゃない?

61 :仕様書無しさん:2011/02/19(土) 13:13:14
>>56
ああ、すまないね。理解できないか、俺が悪かった。

62 :仕様書無しさん:2011/02/19(土) 13:14:00
>考えられる「発生する例外の種類」を列挙
これが理解できないとは・・・ゆとりの人なのか・・
ごめんな

63 :仕様書無しさん:2011/02/19(土) 13:14:42
>>54
>なんで俺にだけ

お前の方だけ下位から上がって来たモンをそのままユーザに見せてるから。
MessageBox()を使うな、とは言ってない。

>>28 >そしてこのようなことができる。
について「そのようなことはすんな」っつってんの。
なんでe.getMessageを表示しようとするんだよ?
なんで例外を投げる方が「画面にどう表示するか」を意識せにゃならんの?

>それじゃあ、どう対処するかなんて・・・

対処せにゃならん、てところに思考が及んでないこと自体が問題。

64 :仕様書無しさん:2011/02/19(土) 13:14:49
ワラタもう60かよw

65 :仕様書無しさん:2011/02/19(土) 13:17:20
>>60
例外処理中に、メッセージボックス表示させる必要がある事を知らせる
フラグを立てて、そのフラグを誰かが見つけて実際に表示するって事?

66 :仕様書無しさん:2011/02/19(土) 13:17:45
>>62
だから、発生する例外の種類は
JQueryと一緒と言ってるだろ?
何が不満?

67 :仕様書無しさん:2011/02/19(土) 13:19:40
>>63
> なんでe.getMessageを表示しようとするんだよ?
> なんで例外を投げる方が「画面にどう表示するか」を意識せにゃならんの?

例外投げる方は、ユーザー用のmessageをセットしてるだけだろ?
それを画面に表示するかは、例外を受け取った側(catch)が
やってることじゃん。コードよく見ろよ。

68 :仕様書無しさん:2011/02/19(土) 13:49:31
>>65
その状況が既に設計をミスってる気がしなくもないけど、
言語環境によっては、インタラクティブな処理が要るなら、
同期イベントでコールバック的にUI層まで上がってから
例外処理まで戻って来れたりする。

69 :仕様書無しさん:2011/02/19(土) 13:59:40
>>68
要するに、ムリがあるんだよ。 みんなが同音異句に、そういう事を言ってる。

70 :仕様書無しさん:2011/02/19(土) 14:01:05
すなおにcatchでメッセージボックスを表示しろってことですな。
もちろん、ユーザーインターフェース層のcatchでね。

71 :仕様書無しさん:2011/02/19(土) 14:01:33
しかしわかりやすい馬鹿だなぁ
俺が多数キリッ

72 :仕様書無しさん:2011/02/19(土) 14:03:09
俺が小数キリ?

73 :仕様書無しさん:2011/02/19(土) 14:03:45
俺もわかってて相手してるよw
本人だけでしょ気付いてないの…

74 :仕様書無しさん:2011/02/19(土) 14:04:26
しかしまあ、まともな反論がなくなったな。
言い負かしすぎたか?

75 :仕様書無しさん:2011/02/19(土) 14:06:07
例の本人さんがいなくなると、とたんに静かになるからね。
これだけ例外全盛期なのに、例外否定とか
わかってないだけじゃんだし。

76 :仕様書無しさん:2011/02/19(土) 14:06:25
まともな事書こうとしても言い負かされるから、分かりやすい煽りしかしなくなってるしな。

77 :仕様書無しさん:2011/02/19(土) 14:08:14
じゃあ、世の中の決定的な意見をどうぞ。
例外はエラー処理が充実してます。

http://itpro.nikkeibp.co.jp/article/COLUMN/20070925/282909/

> 最近はネットのコードでもエラー処理が充実しているのもあるが,やはりそれは例外。



78 :仕様書無しさん:2011/02/19(土) 14:09:16
whileのなかで
try catchをあたかも条件分のごとく使うソースを見たことがあるな

そのブロックが2kぐらいあって、読みきるのに時間かかった覚えがあった

79 :仕様書無しさん:2011/02/19(土) 14:09:50
>>67
>ユーザー用のmessageをセット
は無いわ。

文言変更になったらロジック担当に仕様変更入れるの?

80 :仕様書無しさん:2011/02/19(土) 14:10:41
それはどっちかつーと例外より1ブロックに機能詰めすぎなのが問題なんじゃねw

81 :仕様書無しさん:2011/02/19(土) 14:12:02
>>79

>>25のコードがロジックにメッセージが入ってたから
それに従ったまで、文句なら>>25に言いなさいね。

82 :仕様書無しさん:2011/02/19(土) 14:13:09
>>80
いや、例外を使わなければ、
2k行のコードがたった一行になるんだよ。

83 :仕様書無しさん:2011/02/19(土) 14:14:25
>>27
俺がなにいってるのかわかってねぇな
goto使わなきゃコピペするときに1ブロックで済むのに
いちいち関数の下までいってラベルの中身拾ってくるの面倒だろうが
って言ってるんだよ

84 :仕様書無しさん:2011/02/19(土) 14:17:01
コピペねぇ

85 :仕様書無しさん:2011/02/19(土) 14:17:46
うるせぇな。コピペの何が悪いんだよ

86 :仕様書無しさん:2011/02/19(土) 14:20:31
分からないでコピペしてるから

87 :仕様書無しさん:2011/02/19(土) 14:23:06
結局例外が悪いんじゃなくて、例外を正しく使えないやつがいるのが問題なだけだよな
んで、正しく使えてない例外のせいで例外が悪いと決め付けて学ばないやつが
悪い例外の使い方しない、っていう馬鹿のスパイラル

88 :仕様書無しさん:2011/02/19(土) 14:24:43
例外を使う場合と使わない場合ではソフトウェアの構成までちがってくるよな。

たとえばメッセージを出すにしても、エラーが起きた情報ってのが知る必要がある。
たとえばファイルが開けなかったときのファイル名とか。

戻り値基本的にエラーがintとか単純な方だから、たとえばファイルを開けなかったという情報だけを返して、
そしてエラーを受け取った側がエラーメッセージに必要な情報をかき集める。

でも例外だと、ファイルが開けなかったという情報じゃなくエラーがオブジェクトだから、
様々な情報を付加できる。つまり、エラーを出す側がエラーの情報をかき集める。

ここまでがロジック部分で、それをどう表示するかは別のところで共通に処理することができる。
エラーのオブジェクトに必要な情報が含まれているから、メッセージを表示する段階では
シンプルに作ることが出来る。

89 :仕様書無しさん:2011/02/19(土) 14:27:16
>>88
えー、戻り値だって引数で詳細取得できるようにしたらかわんないじゃーん
俺は例外は明示的な記述ができないって1点だけがデメリットで
それがプロジェクト全体でかなり巨大な負債になってしまうことが嫌なだけなんだけどね
パッっとみてわかんないっしょ?
ドキュメントまでみないとなんの処理してるのかわからない

90 :仕様書無しさん:2011/02/19(土) 14:27:22
>>81
>>25は表示メッセージを戻り値に設定するようなことはしてないからね。

わざわざ例外を投げ直すように変更する理由は
UIとロジックの分離だと見たし、妥当だと思うけど
結局分離出来て無いのが半端。

>>27は見てくれだけ世間を真似てみたけど
失敗した、と見える。

>>25がどうこう言うなら素直に1つめのcatchで
MessageBox()を呼んでおけよ。
それなら何も言わんよ。

91 :仕様書無しさん:2011/02/19(土) 14:29:08
>>90
>>27じゃなくて>>28だった

92 :仕様書無しさん:2011/02/19(土) 14:30:22
>>89
> えー、戻り値だって引数で詳細取得できるようにしたらかわんないじゃーん

その場合、戻り値の型は何型するのか聞いていいか?

答えに詰まっただろう?


93 :仕様書無しさん:2011/02/19(土) 14:31:08
>>92
俺はいつでもbool型

94 :仕様書無しさん:2011/02/19(土) 14:31:24
>>89
わらかないのは仕様理解が不足してるからじゃ?

95 :仕様書無しさん:2011/02/19(土) 14:31:59
>>90

> >>25は表示メッセージを戻り値に設定するようなことはしてないからね。

え? だれが表示メッセージを戻り値に設定した?w


どうやらゴールが見えてきたね
お前が赤っ恥をかくというゴールが。


96 :仕様書無しさん:2011/02/19(土) 14:33:19
>>93

それは要するにこの一番目のパターンだろ?


>>13
> 関数の戻り値に値とエラーコードを混ぜないというのは、
>
> int errorcode = func(param, &out_value);
>
> もしくは、
>
> int value = func(param, &out_errorcode);
>
> のどちらかの形式を使えということ
> tryParseはこれに従っている。
>
> int value_or_errorcode = func(param);
>
> これはいけない。変数名からしていやだろ?


97 :仕様書無しさん:2011/02/19(土) 14:36:19
>>94
戻り値なら理解できるのに例外はtryの中身全部しらべないと確認できないだろ
んで、大抵はドキュメントとソースが食い違ってて例外なんて誰も把握していないと
担当者のオナニーで終わってる宙ぶらりんな例外ばっかりなんだよこの世はw

98 :仕様書無しさん:2011/02/19(土) 14:38:16
>>97
なんで戻り値なら理解できるのさw

> 俺はいつでもbool型

こんなこと言ってるやつもいるだろ。



99 :仕様書無しさん:2011/02/19(土) 14:39:39
>>98
それ書いたのも俺
戻り値はbool、詳細は引数で

100 :仕様書無しさん:2011/02/19(土) 14:40:32
>>99
C言語のライブラリはそうなってないよね?

文句付けないの?

101 :仕様書無しさん:2011/02/19(土) 14:40:43
>>97
>>87

102 :仕様書無しさん:2011/02/19(土) 14:42:51
もうわかったと思うけど、戻り値エラーの欠点の一つは、
このようにライブラリや方針によって
エラーをどう返すかがバラバラn所

103 :仕様書無しさん:2011/02/19(土) 14:46:57
>>95
下位が上位に対して通知するエラーの情報に
上位が表示したいメッセージを含めてない。

>>25はエラーを戻り値で通知してるが、戻り値に含めてない。

>>28はエラーを例外で通知してるが、例外に含めてる。

104 :仕様書無しさん:2011/02/19(土) 14:49:04
どうでもいいような内容に...

105 :仕様書無しさん:2011/02/19(土) 14:51:12
>>103
どうやら気づいてないようだからw
ちゃんと言っておくね。>>28の略っていうのは

こういう意味だよ。

try {
   try {
     checkXXX();
   } catch(Exception e) {
     throw new MyException("XXXXXX", e);
   }
} catch(MyException e) {
  MessageBox(e.getMessage);
  printlog(e)
}

はじめから、例外を関数外なんか投げてません。

106 :仕様書無しさん:2011/02/19(土) 14:54:30
>>107
そりゃそうだよ。

だって元々のコードが、エラーをチェックしたその場所で
メッセージを表示してるじゃん。

もともとのコードが悪い。

エラー値を返す前にエラーを表示しているという
クソコードなんだよ>>25は。

だから文句は>>25につけなさい。

107 :仕様書無しさん:2011/02/19(土) 14:54:45
ぶっちゃけひどい例外の使い方するのは、よくわかってないから例外ダメダメいってる連中なんだよな
適切に使われてる分には困るこたねーよ

108 :仕様書無しさん:2011/02/19(土) 14:56:00
>>107
それは戻り値にも言えることだろ

109 :仕様書無しさん:2011/02/19(土) 14:58:28
だから例外の駄目なところは明示的に書けないところだけだって
戻り値と例外の違いなんてそこしかないぞ

110 :仕様書無しさん:2011/02/19(土) 14:58:55
例外で酷い使い方が横行するならgotoと同じで使用を自粛すべき

111 :仕様書無しさん:2011/02/19(土) 15:00:12
>>109
何を明示的に書くかが違うだけだろ。

例外は、エラーを無視するコードを明示的に書く。エラーの存在チェックは省略してもやってくれる。
戻り値エラーは、エラーの存在をチェックすることを明示的に書く。チェックを省略したらエラーが起きたことを無視する。

112 :仕様書無しさん:2011/02/19(土) 15:01:48
  ∧_∧   
 ( ´∀`)< ぬるぽ

113 :仕様書無しさん:2011/02/19(土) 15:07:33
>>105
全然気付かんかった。

そのメソッドの上位にエラーが伝わんないとか、
メソッド仕様が根本から変わってんじゃねぇか。


それは、まぁともかく。

メソッドが、自分が想定してるエラー処理パスにおいて、
自分のために例外投げるのって普通なん?
それもわりと意外だった。
自分の処理が中断した時に上位に通知するのが原則だと思ってんだが。

114 :仕様書無しさん:2011/02/19(土) 15:07:45
>>110
gotoはreturnやbreakなんかで置き換え可能。
だから使わなくてプログラムは作れる。

よく言われることだけど、今では
エラー処理に関してはgotoを使っていいと言われているし、
実際LinuxのKernelのソースコードなんかも
エラー処理の部分でgotoはよく使われている。

なぜなら、C言語にはreturnやbreakのようにエラー処理を
効率的にやるために置き換える命令が存在しないから。

で、エラー処理をgotoを使わずに行える専用の命令として作られたのが
例外なんだよ。実際Javaなんかはgotoを本当に使わなくても作れるようになってる。

例外はgoto不要論が行き着いた先でもあるんだよ。

115 :仕様書無しさん:2011/02/19(土) 15:08:44
>>113
お前がレス遅いから、先にレスした。

>>106の内容がお前のその答えに対するレスだ。

116 :仕様書無しさん:2011/02/19(土) 15:11:20
gotoの代わりにしか見えんけど

117 :仕様書無しさん:2011/02/19(土) 15:12:40
>>116
gotoの何が悪いかを知っていれば、
gotoから悪い部分を取り除いたものが
例外ってわかるはずなんだが。


盲目的にgotoだから駄目だという時代は終わってるよ。
何故駄目かを考えないと。

118 :仕様書無しさん:2011/02/19(土) 15:16:49
 error = checkXXX(checkee);
 if (error) {msg = "error1"; break;}
 error = checkYYY(checkee);
 if (error) {msg = "error1"; break;}
  :
return !error;

みたいなのみるともうちょっとマシなやり方あるだろって思っちゃうな

119 :仕様書無しさん:2011/02/19(土) 15:21:55
>>115
>>25はメッセージを表示したあと呼び出し元にfalseが返るんだけど
>>105はメッセージを表示したあと呼び出し元に例外が上がらない件について、
>>106がどう関係してるのか、良ければもう少し詳しく頼む。

120 :仕様書無しさん:2011/02/19(土) 15:22:33
>>25のコードはエラーメッセージを出した後に
戻り値を返しているから根本的の間違いなんだよ。
あれをベースにしたら、どうやっても駄目なコードになるに決まってる。
その原因は>>25

じゃあ、>>25のコードをまともに書き換えようとこうなる。

bool func() {
 if(!checkXXX()){
   return false;
 }
 ・
 ・ その他の処理
 ・
 return true;
}

だが、このコードではエラーメッセージがなくなる。
じゃあエラーメッセージをどうやって出すか。

考えれば考えるほど、例外の素晴らしさに辿りつくはずなんだがね。

121 :仕様書無しさん:2011/02/19(土) 15:24:49
>>119

> >>25はメッセージを表示したあと呼び出し元にfalseが返るんだけど

その設計が大間違い。
メッセージを出すのはエラー情報を受け取った側が出すもので、
メッセージを先に出したらいけない。

ロジック部分にUIが混ざってる。
UI(メッセージボックス)はロジック部分が終わってから
つまり戻り値を受け取ってからするべきこと。

例外を理解してない人って、こういう設計感が欠けてるんだよな。


122 :仕様書無しさん:2011/02/19(土) 15:25:53
だれも「例外を使っていけない」っと言うわけじゃない。
例外でエラー処理をする奴はアホだと言っている。

>盲目的にgotoだから駄目だという時代は終わってるよ。
>何故駄目かを考えないと。
お前が終わっているだけだよ、気づけよ。

123 :仕様書無しさん:2011/02/19(土) 15:26:30
例外でエラー処理をしなかったら
なんに使うんだよw

あ、答えなくていいよw

124 :仕様書無しさん:2011/02/19(土) 15:28:57
普通は
例外メッセージ = 例外の型の名前
ってところか
サーバやOSからの応答文字列なんかをそのままフィールドに保存して渡したりはするけど

125 :仕様書無しさん:2011/02/19(土) 15:30:28
だから、昔のgotoの使い方にみえるってこと

126 :仕様書無しさん:2011/02/19(土) 15:30:31
switchのGOTOは使うけどな
あれは便利

127 :仕様書無しさん:2011/02/19(土) 15:38:42
>例外でエラー処理をしなかったら
>なんに使うんだよw
アホ丸出しだな、俺が>>14で書いた通り
>例外が起きたら、やることは2つ「リカバリーとリソース保護」だ。
なぜ例外でエラー処理をする馬鹿がこんなに多いのか?

128 :仕様書無しさん:2011/02/19(土) 15:40:45
じゃあエラー処理はどこで判断してやるんだっていう

129 :仕様書無しさん:2011/02/19(土) 15:42:09
>>120>>121

うーん、よくわかんね。
せめてこうじゃねぇの?

try {
   try {
     checkXXX();
   } catch(Exception e) {
     throw new MyXXXException(e);
   }
} catch(MyXXXException e) {
  MessageBox("XXXXXX");
  printlog(e)
}

130 :仕様書無しさん:2011/02/19(土) 15:45:30
>>113
> 自分のために例外
そっちが楽なときはそうするかなー

真偽以外の結果が欲しい場合とか、いくつかのメソッドでの例外として
同じ復旧が必要な処理がいくつかある場合とかに、便利
自分の中だからフィールドとかで値渡してもいいけど
判定したりしないといけなくなる手間考えると、
複数の同類メソッド並べてtryで囲って、ってほうがめんどくさくない

例外newするのに困るほどパフォーマンス云々がシビアな環境でやるなら考慮もいるだろうけど
昨今じゃそんなの必要とするのは、組込みみたいな泥臭い業界でも減ってるし

投げるものも基本的には既存の例外が殆どだけど
業務例外的なものをExceptionクラスでやると、内部知らない人がぱっと見紛らわしくなったり
不具合も捕まえてしまう可能性もあるから、
プロジェクト内で使う汎用例外みたいなの用意してたりもすることも

131 :仕様書無しさん:2011/02/19(土) 15:46:57
>>128
>じゃあエラー処理はどこで判断してやるんだっていう
アホ発見w、例外処理が実装されていない言語では
エラー処理はしないとでも?w

132 :仕様書無しさん:2011/02/19(土) 15:47:01
ごめん、知能障害でもあるんじゃないかってバカが混ざってるようにしか見えないwww

133 :仕様書無しさん:2011/02/19(土) 15:54:49
(´・ω・`)あのあの
(´・ω・`)また用語の意識あわせから始めないといけないんじゃないの?

自分はエラー処理も復旧もだいたい同じ意味で使ってるけれど。
正常系に戻すための手順であって、具体的には代替処理か、ロールバック、リトライ。
calleeで正常系へと戻せなければ基本は再スロー。あとはcallerがどうにかするだろう的な。

あとは、正常系は本来の目的までのルート
異常系はメソッド内で片付かなかった問題を正常系に戻すまでのルート
代替処理(文字を数値に変換できなかった例外をうけて0を代入するとか)なりリトライなりを
行う部分で、そこで例外が片付けばそっから先は正常系

134 :仕様書無しさん:2011/02/19(土) 15:56:28
今日初めて見たけど
> (´・ω・`)あのあの
> (´・ω・`)また用語の意識あわせから始めないといけないんじゃないの?

2chの場合人がすぐ入れ替わるから、あ・た・り・ま・え

135 :仕様書無しさん:2011/02/19(土) 15:59:03
そんな言い方ってない

136 :仕様書無しさん:2011/02/19(土) 16:00:06
例外は大規模向きで
戻り値エラーは小規模用だよな。

言語機能もそうだけど、
ここで話している人のやりとりを見ると、
戻り値エラーの人は小さな部分しか考えてなくて
パッチ当てる感覚で行き当たりばったりの対応、
自分一人でやる。俺はできるからいいんだみたいな話し方で、

例外の人はシステム全体のことを話してる。
設計とかパターンとかフレームワークとかスキルも知識も
違う多人数開発でどれだけ統一させて作るかってそんな感じ

137 :仕様書無しさん:2011/02/19(土) 16:01:04
始めて見たスレで一言目がスレ違い
ついていけないなら無理にレスしなくても大丈夫ですよー^^

138 :仕様書無しさん:2011/02/19(土) 16:11:13
>>136
違うな。大規模プロジェクトでは普通例外禁止の規約が適用される。
例外禁止、メソッドの引数禁止、プライベート禁止、これぐらいは常識

139 :仕様書無しさん:2011/02/19(土) 16:12:55
>>136
自分の処理内なら戻り値の型がどうのとか気にしなくていいしなー

例外の使い方がよくわかってない人は、基本的に同じような処理をベースに
コピペ切り貼りして、なんも知らないとちょっと分かり辛い例外の使いまわし方とか
良く理解しないまま真似て事なきを得ちゃってるから、ちょっと難しくなると
わかんねーようぜぇってなってしまうんだと思う

特に、仕事として仕事でしかコーディングしない人、最近の流れを知らない人みたいな
興味を持たない人だったりするとそんな感じ

難しく考えないで、戻り値が複数ある、程度の認識でも充分だと思うんだけどね
通常の戻り値は正常な値だけで、異常の場合は複数の戻ってくるパターンがある、ってだけ
try {
 正常な戻り値 = func();
} catch (Type1Exception 異常な戻り値1) {
 //リカバリー ロールバック リトライ 再スローなど
} catch (Type2Exception 異常な戻り値2) {
 //リカバリー ロールバック リトライ 再スローなど
}

140 :仕様書無しさん:2011/02/19(土) 16:13:23
>>138
COBOLだと大規模でも
そういうことありそうだなw

141 :仕様書無しさん:2011/02/19(土) 16:13:46
>>138
よう蛙。そんなに自分の井戸が自慢か?

142 :仕様書無しさん:2011/02/19(土) 16:16:53
catchの中でリトライするか?
例えば10回までリトライする場合、try, catchのネストが10段になるじゃん

143 :仕様書無しさん:2011/02/19(土) 16:17:58
どうやって、catchの中でリトライするんだ?
ネスト的に無理だろw

144 :仕様書無しさん:2011/02/19(土) 16:23:48
例外が出たら出なくなるまでリトライする場合ってどうするの?こんな感じ?
while(bool retry=true) {
  try {
    例外を出すかもしれないメソッド();
    retry = false;
  } catch(とある例外 ex) {
    retry = true;
  }
}

145 :仕様書無しさん:2011/02/19(土) 16:24:02
>>142
普通に考えたらこう

int func() {
 int retry_max = 10;
 int count = 0;
 while(1) {
  try {
    int ret = process();
    return ret;
  } catch(Exception e) {
    count++;
    if(count > retry_max) {
      throw e;
    }
  }
 }
}

146 :仕様書無しさん:2011/02/19(土) 16:26:59
ファイルアクセスや通信なんて、テメェのスレッドでやらせるか?

147 :仕様書無しさん:2011/02/19(土) 16:27:11
>>144
while(1) {
  try {
    例外を出すかもしれないメソッド();
    break;
  } catch(とある例外 ex) {
  }
}

いつかは例外が発生しなくなると
わかってる前提じゃないと使いたくないけどね。

148 :仕様書無しさん:2011/02/19(土) 16:27:56
>>142
catch句の中でリトライするって意味で使ってたわけじゃないんだけど、
こりゃ使い方よくないわな。スマソ

物凄く簡単に書くなら、こういう感じのイメージ

int i = 0;
while (i++ < 10) {
 try {
  retryFunc();
 } catch (MyException ex) {
  continue;
 }
  :
}

自分の中だけでリトライできない場合で、リトライできる場所がキャッチしてやればOK
何回リトライ、っていうか無限ループしてるような処理で考えてもらったほうが分かりやすいかも?

149 :仕様書無しさん:2011/02/19(土) 16:28:37
>>145
参考になるわ。
結構小さい単位で関数を切るんだね。
もしかしてエラーハンドリングが必要な箇所ごとに関数を分けないとだめなのかな。

150 :仕様書無しさん:2011/02/19(土) 16:30:21
>>149

>>148のようなやり方もあるし、
やりたいようにやればいいと思うよ。

151 :仕様書無しさん:2011/02/19(土) 16:31:54
例外分かってないのってコボラーじゃね?

152 :仕様書無しさん:2011/02/19(土) 16:34:26
失敗したら即リトライ再開とかw

153 :仕様書無しさん:2011/02/19(土) 16:34:30
最近発表されたばかりの論文だが、例外使用時の方がシステムの不具合が多くなるそうだ。
学会では例外禁止がすでに常識

154 :仕様書無しさん:2011/02/19(土) 16:36:47
>>152
くだらん突っ込み入れるなよ。

やりたいようにやればいいだろ。
やり方ぐらい一瞬で思いつくだろうが。

155 :仕様書無しさん:2011/02/19(土) 16:37:14
>>153
そうか、学会か。

156 :148:2011/02/19(土) 16:37:30
ユーザー入力値をチェックして間違えてたら入力値不正例外を投げる
入力受け付ける処理は、入力値不正例外をキャッチして、
もっかい入力させなおす、とかそういう感じなのを想像すると分かりやすいかも?

入力チェック処理の中のどこでNGになった場合でも、
チェック処理は入力不正例外を作って投げてやればいいだけなので
自分のなかでどんだけプライベートメソッド持ってたりしても、
どこからでも即異常系のreturnができる、みたいな使い方できるのがメリット
例外処理するほうも共通のやり方で出来るように例外をきちんと設計してあれば、
チェック処理増やしても変更が必要ないし、チェック処理自体をモジュールに出来るから
追加削除がしやすくなるのん

157 :仕様書無しさん:2011/02/19(土) 16:38:10
ソースのない多数の意見w

158 :仕様書無しさん:2011/02/19(土) 16:38:38
>>154
痛い所突かれたようでw

関数内はブラックボックスっていうのなら、せめてその中で他に迷惑
かけない様な実装する必要がある。

それが、マナー。

159 :仕様書無しさん:2011/02/19(土) 16:38:48
学会を馬鹿にするな。
俺は学会員だぞ。

160 :仕様書無しさん:2011/02/19(土) 16:40:32
渡されたファイル名が空文字列だったので例外投げました(キリッ

161 :仕様書無しさん:2011/02/19(土) 16:40:59
>>158
は? すぐにリトライしたら駄目なら、
すぐにリトライしないようにすればいいじゃん。
それだけだよね?

他に迷惑?なにそれ?
何が迷惑を書けてることになるって?

俺、すぐにリトライしない方法の
具体的な実装の話してないんけど、
何に突っ込み入れてるの?

162 :仕様書無しさん:2011/02/19(土) 16:41:59
>>160
どうしてほしいのさw

163 :仕様書無しさん:2011/02/19(土) 16:43:11
ブラックボックスというのは、
中でどんな処理を行っているかわからないという意味で、
中から外に情報を教えないという意味じゃないと思うんだけどなー(苦笑)

164 :仕様書無しさん:2011/02/19(土) 16:45:01
起きてからの事ばっかり心配して、起こさない事には脳ミソ使ってない人が、
例外を異常に崇拝してる。

屁理屈付きのスパゲッティプログラムという印象しかない。

165 :仕様書無しさん:2011/02/19(土) 16:45:30
例外に文句付けてるやつって
どうもツメが甘いよな。

色々とおかしいところを指摘されまくる
気分ってどんなだろう。

166 :仕様書無しさん:2011/02/19(土) 16:46:38
>起こさない事には脳みそ使ってない
不具合は起こす起こさないじゃなくて、起きるもの。

お前は今まで一度でも不具合がないシステムを構築したことがあるのか? まともな規模で
ねーだろ

167 :仕様書無しさん:2011/02/19(土) 16:47:14
例外は崇拝するものじゃなくて常識だよ。
ほとんどの言語の標準ライブラリで
使われてるものなんだから、いやでも使って作る物。
それを使わないやつは馬鹿か仕方ない理由がある場合だけ。

168 :仕様書無しさん:2011/02/19(土) 16:47:21
>中から外に情報を教えないという意味じゃないと思うんだけどなー(苦笑)

誰もそんな事指摘してないし。 自分に都合のいい様に相手の話を
ねじ曲げてるだけでしょ。

日本語もロクに理解出来ないくせに、人工言語が理解出来てるとは
思えないね。

169 :仕様書無しさん:2011/02/19(土) 16:49:35
>>168
その前に、他に迷惑をかけるって
話がなんなのか言ってくれないか。
逃げずに。

170 :仕様書無しさん:2011/02/19(土) 16:50:50
コイツ、言葉尻ばっかり捉えてるな。

171 :仕様書無しさん:2011/02/19(土) 16:51:01
>>158
いや、痛いところっていうかただの揚げ足取りだろw

172 :仕様書無しさん:2011/02/19(土) 16:52:34
そういやすぐにリトライをしたら駄目って話は
結局何が言いたかったんだ?

> >>152
> 失敗したら即リトライ再開とかw

言うだけで終わり?
他に迷惑をかけるって
この話から始まってるだろ?

173 :仕様書無しさん:2011/02/19(土) 16:54:28
ファイルアクセスさせる処理が失敗したら、その処理させる為に与えた
情報か環境のどちらかもしくは両方に問題があった事くらい、例外投げ
返されなくても分かるだろ普通。

じゃあせめて、与える情報の正当性くらい検証してからアクセスさせて
あげようかって考えるのが、まっとうな人間の考え方。

174 :仕様書無しさん:2011/02/19(土) 16:54:43
>>149
基本は1機能1メソッド、って考えるといいよ
例えば、ファイル1の文字列をファイル2の末尾に追加ーってサービスがあるとしたら

-ファイルを開くメソッド
-中身コピーするメソッド
-ファイルを閉じるメソッド

コピーメソッドから呼ばれるメソッドで
 -ファイルから文字を取り出すメソッド
 -ファイル末尾へ文字を書き出すメソッド

完結にその機能を表せる名前が付けれる単位で処理を分けていくといいよ
命名にも困りにくいし、メソッド内で何やってるかが名前から予想つくし

>>160
ファイル名事前にチェックすれば例外は発生しない!
検査例外の呪いは知らん!!

175 :仕様書無しさん:2011/02/19(土) 16:55:43
> じゃあせめて、与える情報の正当性くらい検証してからアクセスさせて
> あげようかって考えるのが、まっとうな人間の考え方。

その与える情報が正当でなかった場合に
返すのが例外ですよ。


176 :仕様書無しさん:2011/02/19(土) 16:56:58
>>175
バァァァァァァァァァァァァァカ

177 :仕様書無しさん:2011/02/19(土) 16:57:24
>>175

正論w

つかこいつ、正常系しか考えてないのか?
「与える情報の正当性くらい検証してからアクセスさせてあげよう」

↑で異常系は?

与える情報が正当じゃなかったらどうすんの?ねぇねぇw

178 :仕様書無しさん:2011/02/19(土) 16:59:30
>与える情報が正当じゃなかったらどうすんの?ねぇねぇw

その処理呼び出さなければいいのでは?

オマエは、殴り書きして判別不可能な手書き文字で手紙とか書いて、
分からんかったら聞きに来いとか言ってしまえる欠陥人間なんだろうな。

179 :仕様書無しさん:2011/02/19(土) 17:00:44
ま、自前にチェックしてから
ファイルアクセスすれば、例外なんか起きないというのは
初心者がよくやる初歩的な間違いなんだけどな。

まっとうではない、初心者だ。

なぜなら、チェックしてからアクセスするまでの
ごく僅かな時間で、アクセス不可になる事態が起こりえるから。

そこまで考慮できないんで初心者。

180 :仕様書無しさん:2011/02/19(土) 17:03:25
>>164
そのメソッドで片付かない場合が例外
処理分けず、多機能なメソッドならそのあたりもまとめて考慮できるけど、
巨大なブロックを作ると、UTや修正の影響範囲がでかくなりすぎるだけ

検査例外の呪いで、事前にtester通してるのに例外を処理するよう書かないといけない、
なんて問題もJavaだとあるけど、そういう場合は事前チェックをサボればいいと考えてもいいっしょ
例外をnewすることですら躊躇しないといけない環境だってんなら、しょうがないけど
それなら起こりえない例外をキャッチしといて、コメントで発生しないので処理しないとでも残してあげるのがベター

>>168
脱線すんなってw
すぐ本題から反れてるから馬鹿にされるんでしょ

181 :仕様書無しさん:2011/02/19(土) 17:04:07
レアケースにかこつけて、自分のゆるい設計思想を正当化してみました(キリッ

実際にやらせてみたら失敗しましたって事は、あるかも知れんな。
でも俺、失敗の原因として、そういう可能性についても言及してるし。

都合の悪い事を無視するのは、オマエの一番悪いところだ。

182 :仕様書無しさん:2011/02/19(土) 17:04:33
>>178
くだらん例えは見るつもりはないんでw

ファイルアクセスしなかったとしても、
ファイルアクセスしなかったという事態を
呼び出し元に返さないといかんだろ。

その与えられた情報が正当ではなかったため
ファイルアクセスしませんでしたという情報を
例外で返すんだよ。

183 :仕様書無しさん:2011/02/19(土) 17:05:49
>>172
拡大解釈して、「一回失敗してるのに何もせずにリトライするだなんてありえない!」
って意味何じゃないのかなーって読み取った
でもそれ仕様な話であって、サンプルコードとかに対していう事でもないよね

(´・ω・`)レスする価値もないと思ったので、とりあえず無視しました

184 :仕様書無しさん:2011/02/19(土) 17:06:12
ここで>>25のクソコードにつながってくる。

関数の中でメッセージを表示してから
戻り値を返すという糞発想。

設計ができてないってのはこういう所。

185 :仕様書無しさん:2011/02/19(土) 17:07:01
>くだらん例えは見るつもりはないんでw

思いっきり反応してるくせにw

186 :仕様書無しさん:2011/02/19(土) 17:07:23
>>185
そこ、重要だったのか? お前にとっては。

187 :仕様書無しさん:2011/02/19(土) 17:08:11
関数の中でメッセージを表示してから
戻り値を返すという糞発想。

くそなのは同意だが、めっさよく見る。
どうしたらいいんだよ

188 :仕様書無しさん:2011/02/19(土) 17:09:02
(´・ω・`)あのあの
(´・ω・`)見えない敵と戦うのはやめてください

189 :仕様書無しさん:2011/02/19(土) 17:10:39
>>187
つまりスレタイってことだよ!
残ってるのは泣き寝入るか職場に革命を起こすか転職するかだ'`,、('∀`) '`…ハァ

190 :仕様書無しさん:2011/02/19(土) 17:12:15
>>187
プログラムの設計を
ロジック部分とUI部分に分ける。

詳しくはMVCとか調べてくれということにして、

UI部分から、ユーザーのアクションで処理(ロジック)を開始して、
処理した結果をUI部分で表示する。

こうすることでロジックとUIが分離され、
UIを入れ替えて、たとえばCUIコマンドを作ったり、
ユニットテストを行えるようになる。

ロジック部分からは処理結果(例外を含む)を受け取り、
そしてUI部分で処理結果を表示する。
こういうのがいまどきの良い設計。

191 :仕様書無しさん:2011/02/19(土) 17:13:23
>その与えられた情報が正当ではなかったため
>ファイルアクセスしませんでしたという情報を
>例外で返すんだよ。

そんな事するくらいなら、その場でメッセージボックス出せばよろしい。
出せないなら、チラシの裏にでも記録しておけばいい。

呼び出し元は、本来やらせたい事の成否だけが分かればいい。 
正常系は、そういう流れで作られている。

そしてそいつにとっての異常系は、そんな細かい事柄について処理する
ために実装されてはいけない。

オマエが言ってる事は、僻地の役場の便所が詰まった事について、監督
官庁の大臣にあれこれ対処させようとするようなもの。

192 :184:2011/02/19(土) 17:14:02

ほーらな。想定通り>>25のクソコードにつながったw

193 :仕様書無しさん:2011/02/19(土) 17:14:34
>>190
個人的にはお前の言ってることぐらい理解してるんだよ。
問題はそれを理解してない人間が無視できないぐらいいるってことで……

194 :仕様書無しさん:2011/02/19(土) 17:15:28
やっぱり例外を分かってない人ってのは
ロジックとUIを分離するって考えすら無いよなぁ。

その場でメッセージボックスを出すとか
まともな人ならやらないことだよ。

195 :仕様書無しさん:2011/02/19(土) 17:16:15
>>193
> 問題はそれを理解してない人間が無視できないぐらいいるってことで……

それが、日本のソフトウェアの品質が低い原因になってる。

196 :仕様書無しさん:2011/02/19(土) 17:16:22
>>190-191
わらかすなwww
どんだけ息ピッタシなんだよ

どうでもいいけど>>26のギャグもひどいよな

197 :仕様書無しさん:2011/02/19(土) 17:17:20
>>195
んで対策は?

198 :仕様書無しさん:2011/02/19(土) 17:18:02
とりあえずよくわからないけど、食い扶持になるから、っていう職業マの数多いしな
ぶっちゃけこのあたりは興味持ってくれる奴じゃないと、どうしようもないと思う
うちの仕事場、今のプロジェクト用のそれなりに噛み砕いたドキュメントとか用意してあるけど
全く守ってないコーディングしてるやつが腐るほどいるしな

199 :仕様書無しさん:2011/02/19(土) 17:20:22
例外使ってる時はいつもフルボッキです(キリッ

200 :仕様書無しさん:2011/02/19(土) 17:21:33
>>197
コミュニケーションよりも
技術力を付けることが大事。
という考えを普及させること

あたりまえのことなのに、たとえば
スポーツ選手に技術力より英語力のほうが大事と
真面目に言っているバカが多いのがこの業界。

ま、言ってるやつは技術ないんだがw

一見、世界で活躍するためには英語力が必要だから
正しいことを言っているように見えるが、
「そもそもとして技術がなけりゃどうしようもないだろ」ってことを
分かってない。

201 :仕様書無しさん:2011/02/19(土) 17:22:57
>コミュニケーションよりも
>技術力を付けることが大事。
>という考えを普及させること

欠陥人間の本音ktkr

202 :仕様書無しさん:2011/02/19(土) 17:24:18
>>201
なんだ?悔しかったか?

ちゃんと言ってやろうか? お前の技術力は低レベルだ。
例外も分からんようじゃ、わかってる人ばかりの世界に
勝てるわけ無いだろうが。

203 :仕様書無しさん:2011/02/19(土) 17:25:59
っていうか例外を好みだけで否定してる人ばっかだしな
わけがわからないよ

204 :仕様書無しさん:2011/02/19(土) 17:26:10
>>202
そっか、>>201 で見事に看破されて悔しかったのか (´・ω・`)

205 :仕様書無しさん:2011/02/19(土) 17:27:12
>>204
(´・ω・`)そっかー
(´・ω・`)それブーメランだよね

206 :仕様書無しさん:2011/02/19(土) 17:27:24

try {
 //xxxx;
} catch {
 throw new Exception("");
}
ってのを見たときにはマジで例外禁止にしようかと思った。
そのあと冷静に考えて、そのバカ首にした方がいいんじゃねーかと思い
さらに冷静に考えて、首にする権限なんてないって気づいた。

俺に組織の改革なんて無理なんだな



207 :仕様書無しさん:2011/02/19(土) 17:28:10
>>200
常識だよな、それ

208 :仕様書無しさん:2011/02/19(土) 17:28:53
>>196
俺も昔は例外分かってない時代があったから、
どう考えるかなんて分かるんだよw
だから先手を打つことも簡単。

209 :仕様書無しさん:2011/02/19(土) 17:30:12
とうとう自演まで始めましたよ?

210 :仕様書無しさん:2011/02/19(土) 17:30:22
>>206
そこでやるべきは、例外を禁止するのではなく、
例外の正しい使い方を教えることだ。

標準ライブラリが例外はくのに、
例外を禁止することなんて不可能だろう?

正しい使い方を教えないと、
いつまでもそういうコード見ることになるぞ。

211 :仕様書無しさん:2011/02/19(土) 17:30:23
>>197
根本的には、しょっぱい奴をクビに出来る社会にならないと解決しない。

212 :仕様書無しさん:2011/02/19(土) 17:32:47
俺以外はみんな死んじゃえよ(キリッ



なんだ、ただの厨二病か

213 :仕様書無しさん:2011/02/19(土) 17:33:02
>>210
ところが、そいつが上司だから教えるのは無理なのさ。
その上司本人から、コード規約作れって指令を受けて規約検討中だったのよ。

んで、そいつ本人のコードを全否定する規約しか浮かばなかったw

214 :仕様書無しさん:2011/02/19(土) 17:34:53
>>213
それはつまり今が改革の時ってことだよ!!!

215 :仕様書無しさん:2011/02/19(土) 17:38:38
>俺も昔は例外分かってない時代があったから

コイツの器の程度が知れる発言ですな ┐(´д`)┌ヤレヤレ

216 :仕様書無しさん:2011/02/19(土) 17:40:43
(くやしい…ビクンビクン)
(荒らしてやる…荒らしてやる…)

217 :仕様書無しさん:2011/02/19(土) 17:42:05
今日も相変わらず精度のいいブーメラン投げてる奴がいるのなw
名無しでぐだぐだやってるあたりuyより酷いw

218 :仕様書無しさん:2011/02/19(土) 17:57:54
結局、反りの合わない上司の悪口言うためのスレだったのね

219 :仕様書無しさん:2011/02/19(土) 18:06:49
よくあるロールバック処理のサンプルコードを例外で書いた。
・・・が、このサイトでは動かなかった。(Visual C++では動いた)
http://ideone.com/2JeE1

しかし、一体このコードを書くのに、俺はどれだけの時間を無駄にしたんだろうw

220 :仕様書無しさん:2011/02/19(土) 18:17:36
昨日みたダメコード

try {
 :
} catch (Exception e) {
 throw e;
}

おまえはいったい、なにがしたいんだ…

221 :仕様書無しさん:2011/02/19(土) 18:18:51
つまり何が言いたいんですか?

計算途中はテンポラリを使って、最後までうまく行った時だけ、それを
本ちゃんの奴にコピーすればいいんじゃないんですか?

それだと、どんな致命的欠陥があるんですか?

222 :仕様書無しさん:2011/02/19(土) 18:21:06
>>219
労力使ってもらったのに言うのもなんだけど、そこまでやったんなら
コメント付けといてよ。 英文でいいから。

223 :仕様書無しさん:2011/02/19(土) 18:22:52
 /**
  * Hogeを取得します。
  * @return
  * @throws Exception 例外が発生した場合 ←
 public Hoge getHoge() throws Exception {
  :

イラッ
型もあれだが説明も酷い

224 :仕様書無しさん:2011/02/19(土) 18:23:37
Oh、1行消してしまった。分かるだろうけど

225 :仕様書無しさん:2011/02/19(土) 18:29:04
>>220
>>206よりマシ

226 :仕様書無しさん:2011/02/19(土) 18:29:24
ロールバック処理の途中で例外が起きないことは、宇宙の法則で決まってるのだろうか・・・

227 :仕様書無しさん:2011/02/19(土) 18:33:20
>>223
そういうのばっかの環境にいると、例外ばくはつしろってなる気持ちも分からんでもないなw

228 :仕様書無しさん:2011/02/19(土) 18:48:28
>>25
Cでも例外処理にGotoは使わねぇよ。
例外に対応するのはreturn+ifだ。

229 :仕様書無しさん:2011/02/19(土) 18:52:49
>>219
事前にオブジェクトのcloneを作って保持して、例外がおきたら書き戻す、それだけの話じゃないのん?
サンプルコードを起こした意図がイマイチわからないかもー

あとCプラ触ったことないんだけど
 O backup = obj;
こういうのって参照のコピーではなくてクローンになるん?
参照だったら、logicAが終わったタイミングでdata[0]とdata[1]入れ替わっちゃったりしない?

それとそれと、サンプルだからそれでもいいとは思うけれど、
さっきちょいちょい話題にあがってた、処理層を意識するばやい、
アウトプットはそれはそれでまとめたほうがいいんじゃないのん
復旧と出力をまとめると、キャッチ句が多機能になっちゃうし

っていうか、中で弄ってこけたら外で書き戻す、ってよりは
処理するメソッドの成功時だけ参照を更新してやるほうがいいと思うの

230 :仕様書無しさん:2011/02/19(土) 18:53:22
catch の部分が関数の途中にあるのが気持ち悪い。
これ、実用のコードだと、try - catch のカタマリが、関数の中の至る所に出てくるんだろ?

正常系考える時はそこを読み飛ばせとか、ちょっとムリがあるんじゃないの?

231 :仕様書無しさん:2011/02/19(土) 18:54:55
コピーコンストラクタがあるじゃまいか

232 :仕様書無しさん:2011/02/19(土) 18:57:44
>>231
なるほそ。理解したthx

233 :仕様書無しさん:2011/02/19(土) 19:05:59
>>230
机上デバッグとか冗長メソッドとかが大好きな人なん?
っていうかtry-catch句なんて構文の一つだろ
理解できてないから気になっちゃうのかもしれんけど

つか、他人が書いたソースを読むのは勉強のときで
俺なら他人が作った機能を呼ぶならドキュメントを見るけどなw

234 :仕様書無しさん:2011/02/19(土) 19:10:04
>>233
オマエ、全部台無しにするなwwwwwwwww

じゃあ、ドキュメントをうpすればいいのにw

クソコードでお勉強とか、ないわーw

235 :仕様書無しさん:2011/02/19(土) 19:11:34
ああそうか、正常終了したときにデータ更新すればいいのか。
ん?でも処理をリトライする時に、結局データをコピーするよな...
それだと、変数の意味が違ってくるだけじゃないか?

236 :仕様書無しさん:2011/02/19(土) 19:13:32
Javaしか知らないのが混じってるから話が。
検査例外なんかほかにねーってよ。

237 :仕様書無しさん:2011/02/19(土) 19:15:50
>Javaしか知らないのが混じってるから話が。

オマエは、しょーもない事で煽るなよ。

238 :仕様書無しさん:2011/02/19(土) 19:16:50
リトライするのは上位じゃないのかよw

239 :仕様書無しさん:2011/02/19(土) 19:21:54
とまあ、現実でもコードレビューでこんなふうに周りから寄ってたかって
厳しいツッコミ入れられて涙目になってるんだろうなw

240 :仕様書無しさん:2011/02/19(土) 19:24:18
戻り値例外派がひどい。
戻り値で例外を判断するのは構わんが、
例外の内容を戻り値に入れるなよ。
Nullないし-1だけでいい。
何でCがerrno+perror使ってたり、
windowsがGetLastError使ってるか
理解してねぇだろ。


241 :233:2011/02/19(土) 19:26:58
>>234
全部台無しってのは具体的に何がどう台無しになったんだ?
何時もそうだけど、批判するために批判するのそろそろやめたほうがいいぞ
あと何のドキュメントを上げろって言ってんだ?
実際に使うだけなら、コード見る必要なんてないっていう話なんだけど、難しかったかな^^;

>>235
あのサンプルでの話しであれば、ループのなかで値コピーして処理して
結果が問題なければ元のやつに書き戻せばいいんでね

242 :仕様書無しさん:2011/02/19(土) 19:28:17
>>238
それは思ったw
例外を使ったロールバックサンプルっていうから、上位でキャッチして処理すんのかとw

243 :仕様書無しさん:2011/02/19(土) 19:38:56
>>何でCがerrno+perror使ってたり、
>windowsがGetLastError使ってるか
>理解してねぇだろ。

あ、GetLastError はアリなんだ。 そういう仕組実装したらどうかと提案
しようと思ってたけど、ムダに煽られると思って控えてたんだが。

だって、例外投げる必要なくなるもんw

244 :仕様書無しさん:2011/02/19(土) 19:40:27
そこでGoですよ、Cの本家が作った。
戻り値が複数あるからエラーは別に返せるしdeferで後始末もする。
RTEの脱出はpanicとrecoverで大丈夫。
StringもMapも組込型な上GCもアリでダックタイプ、
継承はないけどインターフェースはあり。
要は使えるモノは親兄弟関係なく使え。
が強い型付けの静的言語。ヤんなきゃわからんことはない。

でもtry-catchはありません。例外はない、と言っていいのかな。
X64(86)とARMバイナリはおk。
いかがっすか〜

245 :仕様書無しさん:2011/02/19(土) 19:42:58
あちこちに依存してしまうグローバルな値は使いたくねーけどなw

246 :仕様書無しさん:2011/02/19(土) 19:48:40.14
結論 : 例外は不要

247 :仕様書無しさん:2011/02/19(土) 19:57:45.24
>>241
んー、結局正常処理の最後に、backupへのコピーを付けるだけになる気がするんだ。

248 :仕様書無しさん:2011/02/19(土) 20:02:59.40
>>238>>242
それは、mainが上位じゃ無いと言いたいん?
それとも、3層構造にして、もっとハッキリさせろってこと?

249 :仕様書無しさん:2011/02/19(土) 20:06:04.66
>>248
後者
いやね、例外じゃない場合めんどくさいほうが違いが分かるかなと思っただけ
その程度の差だしどっちでもいいんだけど
メリットを主張するならそっちのほうが比較になっていいんじゃねーかなーって程度の話ね

250 :仕様書無しさん:2011/02/19(土) 20:09:05.38
>>220
それ、もしC#ならthrow eじゃなくて、
throwだけにしとかないと問題が発生する。

251 :仕様書無しさん:2011/02/19(土) 20:12:34.15
>>249
そうか、じゃ考えとく。

252 :仕様書無しさん:2011/02/19(土) 20:24:30.47
>>241
オマエの残念な人格についての話だと思うんだけど、難しかったかな^^

253 :仕様書無しさん:2011/02/19(土) 20:26:26.80
>>250
それも、前に中華に作らせたC#でやってる奴いたわw
幸いこっちのはJavaだったからその手の心配はなかったんだけど
ほんとにそのまんまの書き方だったんだよね
なんもしねーのにcatchしちゃったのは、コピペした結果なのかなぁとは思うけれど

254 :仕様書無しさん:2011/02/19(土) 21:11:44.83
必要に応じて対処出来るように、とっかかりを用意したのでは?

255 :仕様書無しさん:2011/02/19(土) 21:34:05.93
チェック例外でコンパイルひっかかるからとりあえず全部上に投げただけじゃないのか?
握りつぶさないだけマシ…じゃないよなw

256 :仕様書無しさん:2011/02/19(土) 22:06:19.89
>>253
あとで何かするつもりだったけど忘れてしまった

257 :仕様書無しさん:2011/02/19(土) 22:14:11.61
>>255
チェック例外じゃなかったら、無くても良いコードだろうし、別にいいんじゃね。

258 :仕様書無しさん:2011/02/19(土) 22:32:34.75
例外でエラー処理を書く利点として
エラー処理を一箇所で宣言的に書けるという利点がある。
例外処理以外は正常系だけを書けば良いから可視化は良くなるかも...

>>220
どんなシステムか分からないが、例えばEXEとDLLの関係で
DLLの例外をEXEに処理させたい場合に、まずDLLで例外をオブジェクトにマッピングして
EXEに投げると正しく捕まえてくれるとかもあるが...これだけだと分からん。

意味が無いと思うことでも、自分が知識が無いだけの場合も多いからな。
まっ本当に意味がないだけかも知れないが。

259 :仕様書無しさん:2011/02/19(土) 22:34:32.78
>>258
必ず一箇所にまとめられるわけでもないけどね。

260 :仕様書無しさん:2011/02/19(土) 23:38:54.63
例外使っても、あのアホが言うほどキレイにはならない。

261 :仕様書無しさん:2011/02/19(土) 23:42:37.23
あのアホがいうほどって、
どれだけキレイなコードなんだ?

262 :仕様書無しさん:2011/02/19(土) 23:49:32.79
実際、そんなにキレイじゃなかっただろ。

むしろ、つぎはぎだらけのコードになるなアリャ

263 :仕様書無しさん:2011/02/19(土) 23:59:17.78
>>260
あのアホって誰?
なんて言ってたの?

264 :仕様書無しさん:2011/02/20(日) 00:01:49.31
アホがどうとかいうより、
きれいなコードってのが
どんなのかが気になるわけだが。

265 :仕様書無しさん:2011/02/20(日) 00:04:08.05
はっきり言えるのは>>260がアホだってことだけだな。

266 :仕様書無しさん:2011/02/20(日) 00:07:54.63
正常系と異常系にキレイに別れるとか言ってたから、
関数の最後に異常系が固まってるのかと思ったら・・・

267 :仕様書無しさん:2011/02/20(日) 00:19:35.26
えっ…

268 :仕様書無しさん:2011/02/20(日) 00:21:22.09
綺麗に分かれるってのは
関数の最後に異常系がまとまるってことじゃねーだろw

正常系の処理の流れから
異常系が抜き出されるだけで。

269 :仕様書無しさん:2011/02/20(日) 00:25:04.27
綺麗とか汚いとかそういう感覚的な部分で語るやつにろくな奴がいたためしがない

270 :仕様書無しさん:2011/02/20(日) 00:35:12.30
感覚じゃなくてちゃんと説明できるけど?

271 :仕様書無しさん:2011/02/20(日) 00:53:08.32
じゃあ結局、戻り値で条件分岐させた if 節と全く構成変わらんだろが。

正常系も異常系も混然一体となってるところは、全く変わってないじゃないか。

272 :仕様書無しさん:2011/02/20(日) 00:54:57.94
どんだけ可読性が改善されるのかと思ったら、アレだもんな。

正直、その程度なのかって思ったわ。 オマエの程度が。

273 :仕様書無しさん:2011/02/20(日) 01:00:42.81
>>271
if文はエラーを分岐させる命令じゃないだろ?

正常系で、正常な処理の流れとして使われる命令だ。
同じ命令を使っていて、異常系を切り分けるifなのかどうか
ぱっと見て分からんだろ。

274 :仕様書無しさん:2011/02/20(日) 01:03:15.37
>同じ命令を使っていて、異常系を切り分けるifなのかどうか
>ぱっと見て分からんだろ。

普通は、コメントが書かれてますからw

275 :仕様書無しさん:2011/02/20(日) 01:04:50.34
if(check() ==1) {
  /*エラーの場合*/
}

こんな感じか?w

276 :仕様書無しさん:2011/02/20(日) 01:05:59.44
あと、分からんようだから、イメージしてみろ。

正常系と異常系で、領域を色分けしてみ? 例のコードは、シマシマになるんだよね。

正常系なら正常系、異常系な来場系ってな風に、視点をちょっといどうさせたら
知りたい情報がまとめて得られるようになってない。

工夫の足りない、読みにくいコードだよありゃ。

277 :仕様書無しさん:2011/02/20(日) 01:07:29.89
× 異常系な来場系

○ 異常系なら異常系

278 :仕様書無しさん:2011/02/20(日) 01:10:39.55
コメントはコードの動きを説明するものではなくて、
なぜそうするのかを書くところなんだが・・・

try 〜 catch と書かれていれば、コードにこれは例外処理ですと書かれているような物。
コードに書いてある物を、コメントに書き写す意味はないよ。
だから例外を使っていればコメントは不要。

コメントを書きますからという時点で、
それはifが劣っているという証拠。

279 :仕様書無しさん:2011/02/20(日) 01:11:38.58
例のコードってどのコード?

280 :仕様書無しさん:2011/02/20(日) 01:11:49.20
横から失礼

>>276
シマシマになっちゃうのは関数の凝集性が低いからでは?
関数を分割してしまえば問題なさそうですが

281 :仕様書無しさん:2011/02/20(日) 01:13:24.08
>if文はエラーを分岐させる命令じゃないだろ?
>正常系で、正常な処理の流れとして使われる命令だ。

>コメントはコードの動きを説明するものではなくて、
>なぜそうするのかを書くところなんだが・・・


オマエの俺様ルールを強要されても困るんだが。

282 :仕様書無しさん:2011/02/20(日) 01:14:42.46
>>279
>>219

283 :仕様書無しさん:2011/02/20(日) 01:15:49.37
>>281
やっぱり経験が足りんのだな。

正しいコメントの書き方を調べてみ。
ちゃんとそう書いてあるから。

284 :仕様書無しさん:2011/02/20(日) 01:16:28.64
>コードに書いてある物を、コメントに書き写す意味はないよ。

あれ? 順番が逆じゃないか? 逆順なのも、最近提唱された手法か何かなのか?

285 :仕様書無しさん:2011/02/20(日) 01:20:10.01
コメントに付いてきちんとまとめたところがないかな?
これとか参考になると思うが。
http://hiroki.jp/2011/01/11/1393/

286 :仕様書無しさん:2011/02/20(日) 01:21:14.53
>>284
逆順って何だ?

コメントはコードに書いてないことを
書くものだよ。

287 :仕様書無しさん:2011/02/20(日) 01:22:05.07
コメントは、正しい手法に則るために書くんじゃなくて、正しく実装
して正しく保守するために書くべきではないかと。

どうせ数年経ったら言ってることがコロコロ変わってる学説とかに
準拠するためじゃないよ。

288 :仕様書無しさん:2011/02/20(日) 01:25:52.72
頭でっかち君は、本当に職業プログラマーなのかな?

289 :仕様書無しさん:2011/02/20(日) 01:27:23.57
なにか言うたびにボロがでるよなw

今度はコメントの書き方に
ダメだしされてるし。

290 :仕様書無しさん:2011/02/20(日) 01:29:17.90
いや、オマエの事なんだがw

291 :仕様書無しさん:2011/02/20(日) 01:30:14.21
>>288のことね。

292 :仕様書無しさん:2011/02/20(日) 01:33:09.15
あ、失礼。

293 :仕様書無しさん:2011/02/20(日) 01:34:19.65
誰が誰のことを言ってるかなんて
文章見ればわかるだろ。

ぼっこぼこにされてる一人と
その他大勢という構図なんだから。

294 :仕様書無しさん:2011/02/20(日) 01:57:30.75
>>282
やっぱそれなのか。

あのコードが出てきた話の流れがさっぱり見えてないんだけど、
アレに対してコードが綺麗の汚いのってのは酷じゃない?

なんせただロールバックしてみただけで処理の大半が意味ないし、
ほぼ設計もしてないでしょアレ。

前スレからの流れか?

295 :仕様書無しさん:2011/02/20(日) 08:15:29.03
>>293
ぶっちゃけ、そういうの分かってて相手してる俺らも俺らだけどなw

>>294
例外でロールバック(リトライ)あたりの話題なのかなーって思ったけれど
そのあたりはだいぶ前にスレ内で解決してるし、対した意味があるものじゃなかったんじゃないかなー

296 :仕様書無しさん:2011/02/20(日) 08:35:55.91
> try 〜 catch と書かれていれば、コードにこれは例外処理ですと書かれているような物。
ただそれだけ。正常系か異常系かはコード見ないとわからない。

297 :仕様書無しさん:2011/02/20(日) 08:42:54.75
異常系のコードを見るってどこを見る?
そう。try catchの場所ってすぐに分かるよね。

298 :仕様書無しさん:2011/02/20(日) 08:56:25.46
それが散財してたら、すぐには分からない。 アホ丸出し。

299 :仕様書無しさん:2011/02/20(日) 08:56:57.31
散財させなければいいじゃん?

300 :仕様書無しさん:2011/02/20(日) 08:59:12.02
散在

301 :仕様書無しさん:2011/02/20(日) 11:00:54.12
メソッド単位で考えて、異常系のパスはthrowしてる箇所で
catch内は異常系または準正常系

302 :仕様書無しさん:2011/02/20(日) 11:08:46.57
>>297
そりゃ、return でも同じだろ。
errno見てるコードは例外以外ないし。

303 :仕様書無しさん:2011/02/20(日) 11:52:17.55
異常系と正常系の分離ってのは綺麗だとか汚いだとかいう話じゃなくて、
コンパイラがそれらを認識して最適化に利用できると言うところが重要なんじゃないの?

この点で「コメントで済む」とか言うのはダメだし、「散在してたらすぐには分からない」って
いうのは例外に限らず単に読みにくいコードってだけで、コンパイラには確実に伝わって
いる。

304 :仕様書無しさん:2011/02/20(日) 12:11:36.23
>>303
そうでもない。

世の中の流れは、可読性も含む生産性をメインに置いてて、
パフォーマンスはハードで解決する方向になってる。
分野によってはそうじゃないのもあるだろうけど


まぁハードのスペックは、その考えに見合う程度に、
順調に上がってきてると思うよ。

305 :仕様書無しさん:2011/02/20(日) 13:06:18.17
ひとつの関数の中に散りばめられた正常系と異常系(笑)

なのに、

異常系は、一目瞭然(キリッ

306 :仕様書無しさん:2011/02/20(日) 13:07:45.31
>>305
ひとつの関数に散りばめなきゃいいじゃn

307 :仕様書無しさん:2011/02/20(日) 13:08:11.89
多分、情報系のバカ学生が、ディベートの練習でもやっているのでしょう。

308 :仕様書無しさん:2011/02/20(日) 13:32:00.98
>>302
> errno見てるコードは例外以外ないし。

errnoってシステム標準のエラーにしか使わないじゃん。

それ以外は分からないってことだよね。


309 :仕様書無しさん:2011/02/20(日) 13:51:43.08
ふふ、例外はスゲッとか言ってる御仁はスクリプトプログラムしか作れないのよ
ブラウザの例外表示が出るだけなら他に甚大なる被害は及ばないから
まあいいんじゃないの。ブラウザの中の箱庭スクリプト世界で例外最高って
言ってれば

310 :仕様書無しさん:2011/02/20(日) 14:11:00.14
いや、例外はスクリプト言語だけじゃなくて、
C++などのコンパイラ言語にもあるから。
っていうか今時ないのは、CとCOBOLぐらいでしょ。

311 :仕様書無しさん:2011/02/20(日) 14:13:47.45
>>309
例外が出来た背景を知ってたら、そんなことは言えないはずなんだが

312 :仕様書無しさん:2011/02/20(日) 14:28:38.31
まぁ別に有り難がるほどには凄かないわな。

基本は同じ様な処理について、その処理の意味毎に
構文を変えられるようにしただけ。
だからどうやったら効果的に使えるかって話が
後追いで出てくんのよ。
その処理がその構文でしか書けない訳じゃないから。

313 :仕様書無しさん:2011/02/20(日) 14:46:07.34
うん、極論すればアセンブラでなんでもできるしな。
問題はどれだけ分かりやすいか、
どれだけ簡単にできるか、
そういうこと、できるできないの話しているうちは
まだまださ。

314 :おじゃばさま:2011/02/20(日) 14:48:42.35
>>310
なんかそうすると「例外」ってブスなくせにやたらしつこい
女みたいだな。
「おまえなんてどっか行け!」
って言っても
「嫌、あたなのそばにいてトイレにたれたおしっこのしずくを掃除するのっ」
って感じかな

315 :仕様書無しさん:2011/02/20(日) 14:59:13.53
負けず嫌いとかそういうのじゃなくてキチガイなんだと思う

316 :仕様書無しさん:2011/02/20(日) 15:03:20.89
>>314
じゃあ、お前なんてどっか行け!
と言ってみよう。

お前がしつこいかどうか
はっきりするな。

317 :おじゃばさま:2011/02/20(日) 15:13:10.81
例外が出来た背景は
馬鹿たちのために安全な機能の提供からスタート
その副産物が例外だな。実装定義のあいまいさから「副作用」も引き起こす
やっかいものだなあ

318 :おじゃばさま:2011/02/20(日) 15:15:22.21
例外というものが考え出されてから後の
すべての言語に例外が備わっているのは、
例外が優れているから。
それ以外の理由は見当たらない。

319 :おじゃばさま:2011/02/20(日) 15:16:13.32
つまり例外の種類をきちんと調べずトップレベルで捕獲してしらんぷりする
マナーの悪い人が多くなってしまったわけだ

馬鹿「うほっ、なんで例外が?? でも動いているし、スルーしちゃえ」
馬鹿2「うえっ、なんで馬鹿が作ったとこから不明な例外がおれんとこにくるんだ、
スルーしちゃえ」
馬鹿3 以下、延々と続く

320 :おじゃばさま:2011/02/20(日) 15:17:14.97
戻り値エラーだと、エラーが起きたことを無視しやすい。
じっさい、コストがどうとかいって、
エラーを無視するやつが多い。


321 :おじゃばさま:2011/02/20(日) 15:17:45.90
数が多いから優れているとは限らない

322 :おじゃばさま:2011/02/20(日) 15:18:47.40
戻り値でも例外でもエラー処理をきちんとできない「にせおじゃば」は糞だ

323 :仕様書無しさん:2011/02/20(日) 15:19:19.06
馬鹿「エラーチェック?めんどくさい。こんな所でエラー起きるわけ無いよ。」
馬鹿2「バグ?落ちてないからバグじゃないよ。」
馬鹿3「なんでこんな所で落ちてるんだ?このチェックいらね。なくても動いてるし」
馬鹿4 以下、延々と続く



324 :おじゃばさま:2011/02/20(日) 15:20:51.86
にせおじゃばはトリップつけろよな。

325 :おじゃばさま:2011/02/20(日) 15:22:54.40
偽おじゃばの論理だとトリップなどつけなくとも例外で捕獲できるだろうがw

326 :おじゃばさま:2011/02/20(日) 15:28:16.49
つまり例外なら補足できて、
戻り値では補足できないことがある。

327 :おじゃばさま:2011/02/20(日) 15:31:26.77
おじゃばさまって、
休みなのにすること無いのか?
しつこいやつだな。

328 :仕様書無しさん:2011/02/20(日) 15:51:37.87
偽のほう、名前消し忘れてるぞ

329 :おじゃばさま:2011/02/20(日) 15:53:57.53
偽おじゃばさまに言ったんだよ

330 :おじゃばさま:2011/02/20(日) 16:01:25.84
>>323
オブジェクト指向の弱点
バグも馬鹿も継承されてしまうのだな

331 :仕様書無しさん:2011/02/20(日) 16:14:54.59
それの何が悪いの?
一箇所直せば全部なおるじゃない。

それともあんたコピペしてんの?

332 :おじゃばさま:2011/02/20(日) 16:29:43.82
一箇所のために修正したら、他の部分で不具合でたりするな。
だから基本コードを共有してはいけない。
関数なんてもってのほかだ。

333 :仕様書無しさん:2011/02/20(日) 16:34:21.70
>>332
それは、バグじゃなく仕様変更では???

334 :仕様書無しさん:2011/02/20(日) 16:53:23.15
そのときの追加・修正の仕方が

if(〜様向け対応){
追加・修正内容
}

がまとめたためにソースにたくさん入るようなまとめ方だと目も当てられないソースになる
上から下まで全部呼んで関係ない部分はずしてやっと意味がわかるソースもあるしね
強引に一箇所にまとめることはできるがまとめた後の管理まで考えるとちょっと考える面はある

一箇所にまとめたために上記のようなコードがたくさん入ってしまうなら
ぶっちゃけまとめないほうがよかった的ソースは経験したことないだろうか?

335 :仕様書無しさん:2011/02/20(日) 16:56:21.10
>>332
標準ライブラリ涙目。

336 :仕様書無しさん:2011/02/20(日) 17:00:19.58
>>334
state/strategyパターンで解決

337 :仕様書無しさん:2011/02/20(日) 17:23:48.03
>>336
世の中の大半は「知らん」で片付けそうだな

338 :仕様書無しさん:2011/02/20(日) 17:34:25.91
例外を理解出来ない人は
デザインパターンの領域にも
来れないだろうなw

339 :仕様書無しさん:2011/02/20(日) 17:43:32.88
例外処理をポリモーフィズムできたら幾分まともになるかもしれない。

340 :おじゃばさま:2011/02/20(日) 18:59:55.81
>>339

なんのために?って聞いてちゃんと答えられる?

いや、なんかこんな用語見つけたので
使ってみました感がでてるからさ
ちゃんと理解してるのかなーと思って。

341 :仕様書無しさん:2011/02/20(日) 19:15:53.55
お前が言うなw

342 :仕様書無しさん:2011/02/20(日) 20:34:23.65
今日も一日中張り付いてたのかw

343 :仕様書無しさん:2011/02/20(日) 22:38:21.04
>デザインパターンの領域

昔からある組合せのパターンを馬鹿にもわかるように体系化しただけ

344 :おじゃばさまオリジナル:2011/02/20(日) 22:41:09.44
246 :おじゃばさま:2006/10/11(水) 09:17:00
「自分で調べろ」と言う先輩や上司の教えない理由は、
「知らない」か「教えるのが面倒」のどちらかだ。

新人教育の目的は「放置しても勝手に覚える人」に教える事ではなく、
「教えれば出来る人」や「教えないとやらない人」に教える事だ。

肉体労働ならともかく、プログラミングで若い人に負けると言うのは、
仕方ない事ではなくて、ただサボっているだけだ。


345 :仕様書無しさん:2011/02/20(日) 23:20:20.14
5年も前のレス持ってきて何がしたいんだ?
というかなんでそんなこと覚えてるんだ

346 :仕様書無しさん:2011/02/20(日) 23:20:56.62
言わせんな恥ずかしい

347 :仕様書無しさん:2011/02/21(月) 00:03:40.01
>>343
ある程度の知識があれば、それだけの話じゃないってことも分かるんだけどな

348 :仕様書無しさん:2011/02/21(月) 00:25:22.12
で、何の話してるんだ?

349 :仕様書無しさん:2011/02/21(月) 00:30:28.92
例外を分からない=C言語どまり=最新技術についてこれていない。

だから最新の話題をすると、そのすべてを否定するw

350 :仕様書無しさん:2011/02/21(月) 00:33:14.71
自分の頭で考えてないから、すぐに最新とか言い出すんだろうな。

351 :仕様書無しさん:2011/02/21(月) 00:45:23.95
あぁ、最新じゃないね。
実績のある普通の技術。

でも、そこまでも追いついていないから
全部否定する。

352 :仕様書無しさん:2011/02/21(月) 01:28:34.78
でも例外を使うなってろくな理由もない主張は、自分が馬鹿って宣言してるようなもんだわなw

353 :仕様書無しさん:2011/02/21(月) 02:52:17.55
>>338
デザパタは作った奴がオブジェクト指向わかってねぇと思うんだけどな
実際の構造をそのままクラスに落とし込めばいいのであって
あんな妙ちくりんな構造にするメリットねぇじゃん

仕様変更かかったらかかったように直せばいいし
あのデザパタってのは一体何を想定した設計なのかさっぱりわからない
仕様書どおりの構造にクラス作ればいいじゃん
どの工程であんなもん入れる隙間があるのか本気でさっぱりわからない

354 :仕様書無しさん:2011/02/21(月) 03:17:54.33
>>353
多分思ってるより実装よりで使う。
ム板にスレあると思うから探してみたら?

355 :仕様書無しさん:2011/02/21(月) 08:31:51.58
>>354
いいや、過去何度も議論したけど
そいつらは実際の構造をそのままクラスに反映させるようなセンスが欠落してる奴ばかりだった
だからデザパタなんて信仰しちゃうんだと思う
特にシングルトンなんてできる過程が意味不明じゃん(これに限らず他も意味不明だけどな)

この辺はセンスなのかな〜?
素直にクラスにすればいいのになんでかそれができないんだよね
これ信仰する人たちって・・・

356 :仕様書無しさん:2011/02/21(月) 08:35:05.42
こっちのスレでそんな話をひっぱるんじゃねぇ。

357 :仕様書無しさん:2011/02/21(月) 09:15:34.33
>>355
ちょっと計らせてもらいたいんだけど、
ドメイン駆動設計を知ってて言ってる?

358 :仕様書無しさん:2011/02/21(月) 09:25:06.39
>>357
そうやってあんまり関係無い方向から話を進めても結局行き着く先にはなにもないよw

359 :仕様書無しさん:2011/02/21(月) 10:02:50.07
まあ例外とOOはあんまり関係ないな。

360 :仕様書無しさん:2011/02/21(月) 10:25:30.26
>>358
いや、彼の論拠は実際の構造云々のようなんで、それを吹聴するからには…と思って。
この言葉に引っ掛からなければ、実際の構造(笑)レベルだろうし。

361 :仕様書無しさん:2011/02/21(月) 10:31:23.31
色々模索してるのはわかるけど
普通に仕様書にある構造をそのままクラスに反映するのが一番なのに
なんでデザパタなんて割り込む隙があるのかわからない
デザパタ全部読んでもこれが書いてないんだよね
だから大抵の人間は「は?」って思う
「なんで?ふつーにそのままクラスにすりゃいいじゃん」と
これをわからずに○○手法、〜設計、□△図とか作りまくる開発未経験の著者or研究者達とか
この業界の癌にしかなってないと思う
奴等そもそも論文やら本やら書いてて開発やったことあるんだろうか?

362 :仕様書無しさん:2011/02/21(月) 11:08:23.23
>>361
で、それが例外の使い方という側面から見て、何なの?

363 :仕様書無しさん:2011/02/21(月) 11:11:23.97
>>362
いや、脱線してただけ
例外の話続けて下ちい

364 :仕様書無しさん:2011/02/21(月) 11:24:55.73
>>361
そこまで物を知らない状態でよく批判できるな。
せめてGoF位ググってこい。
ドメイン駆動設計なら、ファウラーやエバンスが今まで何を構築してきたか調べてこい。

365 :仕様書無しさん:2011/02/21(月) 12:40:04.56
>>364
お前、頭パーだからそんなもん妄信してんだろ

366 :仕様書無しさん:2011/02/21(月) 13:19:56.30
>>305
width = config["width"].toInt();
height = config["height"].toInt();

こんな風に設定情報を読み取りたいとする。
この時整数じゃない項目を全て列挙し、エラー情報に
乗せなきゃいけない。
君ならどう例外処理する?
※上のコードは例であって
項目は複数あるものとする

367 :仕様書無しさん:2011/02/21(月) 13:25:26.08
>>366
横からだけどコードから言って意味不明なんだけど

368 :仕様書無しさん:2011/02/21(月) 15:09:42.54
>>366
foreach(item in config) { try-catch ]

369 :仕様書無しさん:2011/02/21(月) 16:19:15.06
>>366
先に全部書式合ってるか確認して例外は投げさせるなよ。
メソッドの役割間違えてんぞ。

370 :仕様書無しさん:2011/02/21(月) 18:33:28.91
>>353
>実際の構造をそのままクラスに落とし込めばいいのであって

俺もそう思う。

371 :仕様書無しさん:2011/02/21(月) 18:37:18.31
現実と異なる構造にしたら、現実の構造が変わった時とか、特殊事例が
出てきた時に、どうやって対処していくつもりなんだろ。

現実世界での解決方法が、そのまま適用できなくなっていくじゃん。

372 :仕様書無しさん:2011/02/21(月) 18:39:05.24
>>361
> 普通に仕様書にある構造をそのままクラスに反映するのが一番なのに
そんなこたない。
もしそうなら、仕様書の段階で(必要ならデザインパターン使用して)設計までしておく必要がある。

373 :仕様書無しさん:2011/02/21(月) 18:40:10.01
ぼくちゃんのオナニーに、御社の業務は合わせるべき(キリッ

374 :仕様書無しさん:2011/02/21(月) 18:42:47.42
仕様書をどんなものと捉えてるかによる気がするなー。
もし、設計書のことを仕様書と言ってるようだと、設計書どおりにクラス起こすのが当然。

375 :仕様書無しさん:2011/02/21(月) 19:09:16.46
こいつ、顧客がカネ払って買ってくれるプログラムを実際に作ったことねーわ

376 :仕様書無しさん:2011/02/21(月) 19:12:44.70
>>372
はぁ?ばっかじゃねーの
手段と目的が逆転してるよボクちゃんw

377 :仕様書無しさん:2011/02/21(月) 19:14:59.32
何が手段で、何が目的なんだか。

378 :仕様書無しさん:2011/02/21(月) 19:17:34.62
デザインパターン(笑)を使って顧客の要求を矯正(笑)

379 :仕様書無しさん:2011/02/21(月) 19:17:56.74
>>377
デザパタ適用するために設計いじるとかいってる馬鹿は相手にできないなw

380 :仕様書無しさん:2011/02/21(月) 19:19:13.31
>>378は顧客が設計までしてくれる環境なんだろうな。
そりゃ、顧客の設計を否定するわけにはいかんわな。

381 :仕様書無しさん:2011/02/21(月) 19:20:35.28
デザパタ(笑)肯定派意味わかんね

382 :仕様書無しさん:2011/02/21(月) 19:22:28.79
設計したことないとわかんないだろうね。
って、PGじゃ設計しないか。

383 :仕様書無しさん:2011/02/21(月) 19:22:47.88
全ての発想と手法が、社会常識と正反対だなw

384 :仕様書無しさん:2011/02/21(月) 19:24:24.00
そのまま素直に仕様書に書いてあるもんクラスにすりゃいいのに
まず、はじめにデザパタの適用からはじめちゃうキチガイだから
何発言しても驚かないよ

385 :仕様書無しさん:2011/02/21(月) 19:27:31.93
>>384
仕様書に書いてあるのをクラスにして終わりっていうレベルだと必要ないかもな。

386 :仕様書無しさん:2011/02/21(月) 19:28:21.90
なんや、おどれ、森羅万象を設計してくれるのけ?

387 :仕様書無しさん:2011/02/21(月) 19:28:36.58
>>385
レベルが高くなるとお前のオナニーを実現するための意味不明な中間クラス(笑)がたくさん増えるんだ?

388 :仕様書無しさん:2011/02/21(月) 19:31:12.39
>>387
必要ならオナニーでもやるしかないべ。
自分で考えたオナニーの方がきもちいいって言いたいのはわかるけどな。

389 :仕様書無しさん:2011/02/21(月) 19:31:30.68
オナニーは必要ない

390 :仕様書無しさん:2011/02/21(月) 19:32:53.28
>>389
「ぼくが考えた設計」がオナニーじゃないことの方が珍しいと思うぞw

391 :仕様書無しさん:2011/02/21(月) 19:34:09.24
ところで、自然科学分野のシミュレーションプログラムって、オナニー野郎の
デザインパターン適用できるのだろうか?

392 :仕様書無しさん:2011/02/21(月) 19:34:45.16
クラス変更の影響範囲を切る手法がほとんどだから、
規模が小さかったり、変更がおよそ有り得ないなら
使わんでもいいだろ。

393 :仕様書無しさん:2011/02/21(月) 19:35:36.93
デザインパターンが、世の中の全ての現象を網羅して考案されているとは思えない。

ごく限られた領域でのみ、たまたまうまく適用できている事例が点在しているだけだろ。

394 :仕様書無しさん:2011/02/21(月) 19:42:32.69
>>393
うまく適応できる事例は使った方がいいね。
デザインパターン使わずに考えたら、既存のデザインパターンに似た設計になりました
みたいな車輪の再発明して喜ぶのは本末転倒だし。

べつに、なんでもデザインパターン適応したほうがいいとは言ってないよ。

395 :仕様書無しさん:2011/02/21(月) 19:45:40.13
>既存のデザインパターンに似た設計

バカの発言ktkr

396 :仕様書無しさん:2011/02/21(月) 19:50:09.45
>>361
http://d.hatena.ne.jp/asakichy/20090213/1234485643
もっと詳しく知りたい方は「GRASP」で検索してみてください。

>>394
デザインパターンはよく使うパターンに名前をつけたものなので似た設計に
なるのはよくあることです。

397 :仕様書無しさん:2011/02/21(月) 19:55:31.48
>>396
まぁね。定石を知ってるかどうかの違いといえばそのとおりなんだけど
定石なら知ってる方がいい。

398 :仕様書無しさん:2011/02/21(月) 19:58:19.95
>>397
四十八手の名前知らなくても、ちゃんとまともにセックスできるだろw

399 :仕様書無しさん:2011/02/21(月) 20:06:46.35
下品な奴だな

400 :仕様書無しさん:2011/02/21(月) 20:11:24.86
卑近な例で、分かりやすく説明しただけだが。

401 :仕様書無しさん:2011/02/21(月) 20:12:02.36
デザインパターンは慣用句。知っていれば表現の幅が広がる。

402 :仕様書無しさん:2011/02/21(月) 20:12:48.85
>>394
使ったほうがいいっていつ使うの?
大抵の人は仕様書に書いてある構造をそのままクラスにしちゃうだけなんだよ

403 :仕様書無しさん:2011/02/21(月) 20:25:49.28
デザパタ知らなくても、自然に落とし込んでたら
デコレーターになってたりするんだがな。

404 :仕様書無しさん:2011/02/21(月) 20:29:46.94
でっていう

405 :仕様書無しさん:2011/02/21(月) 20:33:11.60
>>402
完全に下流の工程しか担当しない(リファクタリングの権限がない)のなら仕様書を
そのままクラスに起こすのが正しいと思います。

レビューに参加しているのであればその場で提案します。一人で勝手にすべての構造を決めるわけではないので
(パターン中毒者の存在は否定しませんが)パターン中毒者のオナニーばかりという訳ではありませんよ


406 :仕様書無しさん:2011/02/21(月) 20:37:17.83
そうやってクソシステムが量産されるんですね。わかります。

407 :仕様書無しさん:2011/02/21(月) 20:41:46.72
まだ無知が自分の知らない世界を否定し続けてるのか。
三平方の定理が役に立たないとほざく中学生と同じレベルだと気付かんのかね。

408 :仕様書無しさん:2011/02/21(月) 20:43:34.34
あー、お前さんは、いろいろちゃんと考えてるんですね。 角度とか。

409 :仕様書無しさん:2011/02/21(月) 20:49:14.88
単純に疑問なんですが、否定派の方は
同じ用途で複数の外部システムと連携するようなシステムを開発する際に
どうしてるんですか?状態変数をみてifやswitchですか?

410 :仕様書無しさん:2011/02/21(月) 20:50:55.39
>>369
まぁ、そう思うだろ。最初俺もそう思った。
でも、よく考えたら、例外にするより
事前チェックの方が効率が悪いんだよ

まず、正常時だと数字変換が2回行われる。
それから、例外時だと事前チェックも例外機構使用時も
同じ情報集める必要がある。
さらに事前チェックだと、取得する変数が変わった時に
2箇所も直さなきゃならん。
事前チェックで得すんのは、例外状態での速度だけなんだ。

あとレス番間違えた
×305
○306


411 :仕様書無しさん:2011/02/21(月) 20:54:03.61
なんで自分の知らないものを否定するんですか?

412 :仕様書無しさん:2011/02/21(月) 20:55:03.96
で、何秒得するの?

413 :仕様書無しさん:2011/02/21(月) 20:55:58.13
多分、誰も例外やデザパタを否定してるんじゃないと思うよ?

誰かさんのロクでもねー人格だけを否定してるんだと思うよ?

414 :仕様書無しさん:2011/02/21(月) 20:56:39.29
いやー、本当に想定通りの流れになってるなw

どうせ例外を知らないやつは、新しく・・・もないが
C言語の時代からすれば、新しくて、今普通に使われてる技術を
全て知らないだろうから、

知らない物=全部否定 脳 だろうと仮定して、
デザパタの話題を振ったのだが、想定通り否定してるなw

今度はユニットテストの話でもしようか?
ついてこれないだろう?w

415 :仕様書無しさん:2011/02/21(月) 20:57:53.00
C言語厨ってテストの自動化ってやってるの?

416 :仕様書無しさん:2011/02/21(月) 20:57:57.90
>>414
例外もデザパタもUTも否定しないが、お前は否定する。

417 :仕様書無しさん:2011/02/21(月) 20:57:59.43
想定通りだってw

418 :仕様書無しさん:2011/02/21(月) 20:59:07.07
>>415
ふつうにやるけど。やらないとめんどくせーし。

419 :仕様書無しさん:2011/02/21(月) 21:03:23.29
>>412
速さはどうでもいい。
事前チェックとの同期が
必要なくなってバグ要素がひとつ減る。

420 :仕様書無しさん:2011/02/21(月) 21:07:16.39
すべてのことが事前に分かれば事前チェックは可能だが、
たとえばファイル読み込みとか、事前にチェックしたとしても、
チェックした後でファイルが無くなるとかあり得るからな。
結局は例外に頼ることになるという。


421 :仕様書無しさん:2011/02/21(月) 21:08:12.63
>>410
効率の問題じゃ無くて、関数の呼び方が間違えてるから例外が飛ぶの。
特にそのケースは。

例外はif文じゃないしgotoでもない。
そうしたいならtryなメソッドでも作ってろ。

422 :仕様書無しさん:2011/02/21(月) 21:10:10.98
>>420
そりゃ、ファイルが無いという例外が飛んでくる環境ではそうだろうよ。

423 :仕様書無しさん:2011/02/21(月) 21:13:47.73
この場合、例外が飛んで来るというのは素晴らしい機能なんだよね。

事前にチェックしたのだから、ファイルがあることは確実だろう。
なんて初心者は思い込んで、ファイルをオープンした後の
戻り値チェック省いてしまう。

いわゆるバグなんだけど、例外だとこんな場合でもエラーを
無視することはないので、エラーに気づくことができるんだよ。


424 :仕様書無しさん:2011/02/21(月) 21:16:11.48
>>419
>速さはどうでもいい。

オマエが処理時間の事を言い出したから質問したんだが。

425 :仕様書無しさん:2011/02/21(月) 21:17:57.27
何スレか前から見てるけど、例外が起きる例として、ファイルアクセス
関連の話しか出てこないんだがw

426 :仕様書無しさん:2011/02/21(月) 21:20:01.57
速度が求められることって意外とないんで、
普通のお仕事ならば入力時も読み取り時も両方チェックするのがいいと思う

427 :仕様書無しさん:2011/02/21(月) 21:20:02.62
それにオマエの話だと、あるプログラムのメモリ上でだけの不都合な事象でも、
例外投げてウハウハみたいなはしゃぎっぷりだったんだがw

428 :仕様書無しさん:2011/02/21(月) 21:23:11.54
別にメモリとファイルを区別する必要もないけどね。
データが揮発性かどうかってだけの違いだし。

メモリマップトファイルみたいなものもあるし、
実は二つを区別して考える必要性は少ない。

429 :仕様書無しさん:2011/02/21(月) 21:24:59.76
>>424
事前チェックを主張される方は速度にこだわる方が
多くいらっしゃいますので。
速さ云々書かれる前に封じとこうと思って書いただけ。
応答が1秒未満の処理に速度なんてどうでもいい。

430 :仕様書無しさん:2011/02/21(月) 21:28:28.80
>別にメモリとファイルを区別する必要もないけどね。

>メモリマップトファイルみたいなものもあるし


どこまで行ってもファイルの話しかしないのなw 多分、日本語が苦手なんだろうなw

431 :仕様書無しさん:2011/02/21(月) 21:28:30.25
事前チェックは最適化の範疇だと考えればいいんだよ。

特にやる必要はないけど、重視する必要がある場合のみ
対応する。

432 :仕様書無しさん:2011/02/21(月) 21:29:12.38
>事前チェックは最適化の範疇だと考えればいいんだよ。

俺様ルールktkr

433 :仕様書無しさん:2011/02/21(月) 21:31:56.24
>>430
仮想メモリって知ってる?

434 :仕様書無しさん:2011/02/21(月) 21:35:51.47
>>433
相手の意図をくみとって意思疎通する能力が、著しく欠乏している障害者乙。

435 :仕様書無しさん:2011/02/21(月) 21:39:06.45
仮想メモリのファイルを、誰かに消されていたでござる(キリッ

436 :仕様書無しさん:2011/02/21(月) 21:39:24.24
>>432
お前は、俺様ルール禁止な。

で、お前の意見は?

437 :仕様書無しさん:2011/02/21(月) 22:12:53.69
すげぇ勢いだなこのスレ。
数十レス斜め読みしたけど、誰がどの主張してるか全然分からん。
そろそろ誰かまとめてくれ。

438 :仕様書無しさん:2011/02/21(月) 22:22:00.40
まぁ、プログラミングの作法について、なんらかの意見があるならマシだろ。
ひどいのは、マジでなんも考えてない奴w
10年選手とか言ってても1年選手より使えねぇーのがいっぱい。

439 :仕様書無しさん:2011/02/21(月) 22:23:15.54
と、一年選手がホザいています

440 :仕様書無しさん:2011/02/21(月) 22:24:32.50
なんだ、駆け出し君がキャンキャン吠えてたのかw

441 :仕様書無しさん:2011/02/21(月) 22:35:10.65
>>437
そうやって他力本願寺に参拝するのもうやめましょうよ


442 :仕様書無しさん:2011/02/21(月) 22:56:34.40
職業プログラマーらしからぬ発言だらけだったから、おかしいと思ってたんだよね。 

そしたら案の定、ペーペー君だった訳だ。

443 :仕様書無しさん:2011/02/21(月) 23:08:34.24
基本的に、例外でエラー処理(事前に判定出来る物)をしてはいけない。

しかし、発生場所が複数で対応方法を同一にしたいエラーは
例外にマッピングして一箇所で処理をする。

例外は発生する場所より、それを受止める場所が大事。
将来の事を考えOCPでしっかりと設計しなければならない。


444 :仕様書無しさん:2011/02/21(月) 23:11:34.74
>>441
自分がいつも先輩から言われているセリフを、他人に言ってみました(キリッ

445 :仕様書無しさん:2011/02/21(月) 23:32:30.34
442 名前: 仕様書無しさん 投稿日: 2011/02/21(月) 22:56:34.40
職業プログラマーらしからぬ発言だらけだったから、おかしいと思ってたんだよね。 

そしたら案の定、ペーペー君だった訳だ。
443 名前: 仕様書無しさん [sage] 投稿日: 2011/02/21(月) 23:08:34.24
基本的に、例外でエラー処理(事前に判定出来る物)をしてはいけない。

しかし、発生場所が複数で対応方法を同一にしたいエラーは
例外にマッピングして一箇所で処理をする。

例外は発生する場所より、それを受止める場所が大事。
将来の事を考えOCPでしっかりと設計しなければならない。

444 名前: 仕様書無しさん 投稿日: 2011/02/21(月) 23:11:34.74
>>441
自分がいつも先輩から言われているセリフを、他人に言ってみました(キリッ

446 :仕様書無しさん:2011/02/21(月) 23:35:57.79
自分がコレまでやってきた底辺作業を至高の仕事だったって思ってるんだから
新しいこととか、そういうのを覚えようとは思わんのでしょ
例外は新しかねーけど、それでも、当たり前に使えない奴多いしな

自分も新しいこと全部理解できてるってほど勉強してるとは思わんけど
ろくに知りもせず、あまり理解できないから否定してる奴は単純に馬鹿なんだと思うよ
根拠の出せない無駄認定や、(理解してないから)めんどくさいみたいな否定ばっかで
メリットデメリット語ってるやつはほぼ居ないしな

447 :仕様書無しさん:2011/02/21(月) 23:50:47.94
>>442
職業マとか糞の塊じゃねーかw
工事現場で車の誘導するプロです!ってしたり顔で語られてもな
既に土方根性が染み付いてそうな語り口だし、言うだけ無駄だろうけど


tester-doerの話が出てるけど、例えば文字パースする場合、俺はそのままparseするなぁ
もちろんC#とかならTryParseするけど、用意されてない方が多いし
既存の機能だけで判断できるのに、わざわざチェック処理を再発明するなんて無駄の極み

失敗がある処理ならtryして失敗したらそんときの振る舞いを書く、ただそんだけのことじゃん
設計まで手がけてりゃいろいろ考慮必要だけど、ここで例外についてぐだぐだ言ってる土方じゃ
その手のことを任せられるような人じゃなさそうだしなー

448 :仕様書無しさん:2011/02/22(火) 00:08:09.44
職業PGにろくな奴がいないのは同意。
特に年食った奴。使えない上に頭は固い。不勉強なのに自尊心だけは一人前。
人手不足でしょうがなく使ってみたけど、邪魔にしかならんから即クビだったわ。

449 :仕様書無しさん:2011/02/22(火) 00:22:44.20
技術的反論が出来ない人間は、人を批判する。

450 :仕様書無しさん:2011/02/22(火) 00:36:44.70
人格否定から入る奴いるよね

451 :仕様書無しさん:2011/02/22(火) 13:32:59.47
>>421
じゃtryなメソッドとやらの具体的なコードを見せてくれ。
あと例外機構はreturnでまともな値を返すための代替構文だ。
try catch型は元々オペレーターのオーバロードを綺麗に
書くこととコンストラクターの異常通知が発端になってる。
禿げのC++関連書籍を読んでみろ。

452 :仕様書無しさん:2011/02/22(火) 18:20:01.86
今日もまた、残念な人格のアホタレが口でクソ垂れてるなw

453 :仕様書無しさん:2011/02/22(火) 20:13:32.40
>>451
物の役割は時代と共に変わる

454 :仕様書無しさん:2011/02/22(火) 21:22:58.57
>>453
ifの役割が変わったか?
forの役割が変わったか?
switchの役割が変わったか?
returnの役割が変わったか?
詭弁も大概にしろ。
言語設計事時の役割が変わる事はまずあり得ん。
有るとすれば仕様の改変が行われたときだ。
仕様が変わらないのに変わったようにおもえるなら、
何が起因してどう変わったのか書いてみろよ。

455 :仕様書無しさん:2011/02/22(火) 22:15:48.24
>454
てか、例外の歴史は知んないけどさ。
次々に新しい言語が開発されてんだから
その都度言語設計はされてんじゃん。

forはeachが出て来てカウンティングの
意味合いが強くなったりしたし、
switchはフォールスルーが禁止されて
よりif寄りになったりしてるよ。

456 :仕様書無しさん:2011/02/22(火) 22:51:13.66
予想以上に反響が大きいこのスレは例外に該当するの??

457 :仕様書無しさん:2011/02/22(火) 22:53:03.74
>>455
だからなんなんだ?

returnで戻り値でエラーを返さず
例外を使うようになったりしてるよな。

458 :仕様書無しさん:2011/02/22(火) 23:02:35.94
レベルが高いのか低いのか分からんが
とにかく俺には着いていけない話だ。

459 :仕様書無しさん:2011/02/22(火) 23:13:47.77
>>457
いやさ別に、フツーに言語の仕様は変わってじゃんってだけだよ。

なんで>>454は仕様が変わらない前提で話してんの?
なんか特定の言語に限定した話?

460 :仕様書無しさん:2011/02/22(火) 23:23:22.47
言語の仕様はいい方向には変わるが
悪い方向には変わらないよ。

ということで、戻り値でエラーを返す方式よりも
後にできた例外でエラーを返す方式は
戻り値でエラーを返す方式には戻らない。

もし例外よりもいいものが出来れば、その時は例外はなくなるかもしれないが、
戻り値に戻ることはないし、例外よりも優れたものは今のところ出来ていない。

言語の仕様が変わることがあるんだから、例外も変わると詭弁は要らない。
言語の仕様が変わるという現象が、果たして例外に当てはまるのかどうかの話をするべきだ。

461 :仕様書無しさん:2011/02/23(水) 00:00:48.71
>>460
知らんがな。
じゃあ>>454でそう書けよって話だよ。

まぁ検査例外は評判悪いみたいだけどなぁ。
ああいうのはわりと好きなんだけど、
JAVA使ってないから聞いた話しか分からない。
もうちょっと洗練されて流行るのか、
淘汰されて消えるのか。

462 :仕様書無しさん:2011/02/23(水) 00:01:16.79
>>455
お前の言ってる範囲じゃforもswitch意味合いは変わってない。
お前が言ってるのは、
javascriptやpythonは、アクセス制御がないからあのオブジェクト機能は、
オブジェクト思考とは違うって言ってんのと変わらん。
言語設計者は利便性のため今までと
多少異なる手段を取るが、
目指す機能は一貫してて、同じ
セマンティクスを保たせている。

じゃお前の言う役割が変わるってなんだよって思うだろうが、
それに答えるならクラスと構造体だ。
C++なんかじゃ
構文上両者殆ど差が無い。しかし、意味合いが全く違う。
クラスが構造体を拡張して利用しているのは、
手段であって目的じゃない。オブジェクト思考は構造体に関数を
くくりつける事じゃない。
完全にセマンティクスが別なんだ。
これが俺の言う役割の違い。
じゃ、例外にそんな事起きたか?
スタックトレースやら、送出チェックやら多少の拡張は
有ったがなんらセマンティクスは変わって無いだろ。


463 :仕様書無しさん:2011/02/23(水) 00:07:38.09
論点がぼやけるのは、いつものこと

464 :仕様書無しさん:2011/02/23(水) 08:18:41.22
セマンティクスやコンテクストという言葉は、意味が通るようで全く分からん。

465 :仕様書無しさん:2011/02/23(水) 13:21:28.64
コンテスト=脈絡
状態の変化していく過程
プログラミング界隈ではコンテスト情報の意味が混在してる。

セマンティクス=それが存在する意図
例えば、nullはnullポエラーで
プログラマーが苦しみハゲ散らかすために作られたんじゃない。
存在しない事を表すために作られた。
この存在しない事を表すためという
のがセマンティクス。
他にも、CにGotoが残っているがfor等代替構文が用意されている。
この場合不必要にGotoを使うなというのがセマンティクス。
この意図を無視する事をセマンティクスに反するという。

466 :仕様書無しさん:2011/02/23(水) 14:07:42.76
ミスコンテスト

467 :仕様書無しさん:2011/02/23(水) 15:11:49.48
そいつぁ美人が集まりそうだ

468 :仕様書無しさん:2011/02/23(水) 18:52:09.44
ミス 例外を正しく使えるプログラマ コンテスト

469 :仕様書無しさん:2011/02/23(水) 19:47:58.83
ああ悪かったよ。携帯からの予測変換でよく見てなかった。

470 :仕様書無しさん:2011/02/23(水) 20:13:45.26
いちいち横文字使わずに、日本語で正しく表現してみろや。

471 :仕様書無しさん:2011/02/23(水) 21:06:19.89
セックスとまではちぢまらねぇかw

472 :仕様書無しさん:2011/02/23(水) 21:12:32.73
あの表現に嫉妬してんのか。精進せえよ。

473 :仕様書無しさん:2011/02/24(木) 00:11:36.51
>>470
じゃあ、コンピューターは電算機、
デジタルは計量、ベクトルは有向量、
クラスは群とでも言ってろよ。


474 :仕様書無しさん:2011/02/24(木) 01:36:34.70
日常使うかって言われたら俺は使わんけど
別に意味が分からない単語ではないし、いちいち突っかかるような事でもないわ

475 :仕様書無しさん:2011/02/24(木) 06:21:55.04
発音しないだけで、脳内では常に意識しているくせに

476 :仕様書無しさん:2011/02/24(木) 13:54:15.59
計量はメトリクス、群はグループ

デジタルは離散量、クラスは類

ツッコミ入れるならおちつけよ

477 :仕様書無しさん:2011/02/24(木) 20:31:45.76
俺のビッグコックをヤングレディーにインサートしてヒィヒィ言わせたい

478 :仕様書無しさん:2011/02/24(木) 21:19:32.63
>>476
残念ながら永田町の英和辞書は違うんだな〜。
科学系システムの入札に参加して資料読んで見ると解る。


479 :仕様書無しさん:2011/02/24(木) 21:39:37.87
そんなしょうもない辞書があるのかw

480 :仕様書無しさん:2011/02/25(金) 09:23:13.08
なるほど、科学力がズタズタになってゆくわけだ。

481 :仕様書無しさん:2011/02/25(金) 19:21:29.23
なんか、過疎ってきたな

482 :仕様書無しさん:2011/02/26(土) 00:00:46.06
戻り値厨が一人いなくなるだけで
こうななるのさw

483 :仕様書無しさん:2011/02/26(土) 12:23:35.16
日によってプログラムの書き方が変わるって精神分裂病だよ

484 :仕様書無しさん:2011/02/26(土) 12:50:37.63
誰もそんな話してないだろ。
お前が精神分裂病なのか?


485 :仕様書無しさん:2011/02/26(土) 18:35:42.47
例外中は、例外ばっかり投げてるお騒がせ野郎。

486 :仕様書無しさん:2011/02/26(土) 18:48:22.70
戻ってきたなら、
ちゃんとただいまっていえや。
かまってやらんぞ。

487 :仕様書無しさん:2011/02/26(土) 19:16:17.26
何を言っても馬鹿を露呈するだけの無能だから、
>>485みたいな定型文の煽り文句程度しか書けること残ってないんだよ(´・ω・`)

488 :仕様書無しさん:2011/02/27(日) 01:18:20.23
そんなに怖がらなくてもいいのに

489 :仕様書無しさん:2011/02/27(日) 10:47:25.74
また、例外で被害者が出たぞ

ふらっとC#,C♯,C#(初心者用) Part70
http://hibari.2ch.net/test/read.cgi/tech/1298054350/261-285

490 :仕様書無しさん:2011/02/27(日) 11:13:59.04
ただ単に頭が悪いだけじゃないの

491 :仕様書無しさん:2011/02/27(日) 12:15:51.63
catchの中身になにも書かなければ握りつぶしたことになると思ってたけど
C#ってならないんだ
ちなみに正解は何を書けばいいの?

492 :仕様書無しさん:2011/02/27(日) 12:58:32.92
例外自体はそれほど重要じゃない話なんだけど、
ちょっと頭の体操。
交点座標を求める関数型IS作るとする。
交点の座標を戻り値ないし、引数で返す。
この時、交点を求める基準となる二つの直線(ベクター)が
平行なら交点座標は不定となる。
さて、君らなら、このISをどうやって実装する?

ヒント
2次関数の解をどうやって表す?
cosなどの周期関数を因数分解したときの答えは?


493 :仕様書無しさん:2011/02/27(日) 13:21:00.35
外積。完全にスレ違いと思う

494 :仕様書無しさん:2011/02/27(日) 13:29:04.00
>>493
ごめん。式自体はどうでもいい。
問題は関数のインターフェースね。
どうやって値を返すかって話。
nullを返すなり例外だしたり、
戻り値bool返したり色々あると
思うけどどうするかって話。

495 :仕様書無しさん:2011/02/27(日) 13:42:06.81
返したい情報を持つクラス。完全にスレ違いと思う

496 :仕様書無しさん:2011/02/27(日) 14:10:21.46
>>495
どんなクラス?
不定情報と座標情報を持ってるとか?
具体的に教えてくれ。

別に例外機構は関係ないけど、分野としては
例外処理なんだけどな。
スレタイもあくまで例外機構ではないし。

ま、小さい概念だけだと例外で
大きくみた実装は異なるって話で
広げたかったんだけどな。

497 :仕様書無しさん:2011/02/27(日) 14:28:36.66
じゃあスレ立ててよそでやろうね。完全にスレ違いだと思う

498 :仕様書無しさん:2011/02/27(日) 14:35:04.13
そういう後出しジャンケンみたいなのはダメだろ。
話ひろげたきゃまず自分で出せよ。


499 :仕様書無しさん:2011/02/27(日) 14:47:06.65
>>492
交点は無限遠点とする。

500 :仕様書無しさん:2011/02/27(日) 17:33:50.49
烏丸通と河原町通は、北極と南極で交差する。

501 :仕様書無しさん:2011/02/27(日) 18:12:30.18
>>496
>別に例外機構は関係ないけど、分野としては
>例外処理なんだけどな。
なぜ例外になるんだ? お前の数学の知識はその程度なのか?
その答えが例外だと思っている時点で、数学・システム工学についての知識が薄いことは分かった。

502 :仕様書無しさん:2011/02/27(日) 19:41:42.12
おじゃば乙。

503 :仕様書無しさん:2011/02/27(日) 20:12:12.77
具体的にどうするか論破して、どっかのスレに帰れ的な
レスが付くと思ったが、この程度か。がっかりだな。

結論として、意外に例外扱いしそうでも、しなくていいケースが
潜在してるってとこに持って行きたかったんだけどなぁ。

とりあえず模範解答を出せば、配列で返すだ。要素数の
概念があれば別にリストだろうがなんで構わんけど。
交点が出せれば要素は1、出せなければ要素数は0になる。
で、これが配列で有るために因数分解の解と互換性を持たせられる。
これらの結果は全て配列で表現できるとね。まぁ、cosの
因数分解については無限になるから、配列をオーバーライドして
添字に合わせた
解を取り出せるよう工夫が必要になるけどね。

次第点としては、予め交差してなかった場合返す座標を
引数に渡し交差していなければそれを返す。状況によっては
無駄な先読みが必要になるのであまり宜しく無い。

他、例外的手法。事前チェック、
座標と正否値を返す。それこそ例外機構を使う等考えられるが、無駄や値の完全性という点から見て総じてアウト。

504 :仕様書無しさん:2011/02/27(日) 20:21:25.11
>>503
y-2x = 0と2y - 4x = 0の交点は?

505 :仕様書無しさん:2011/02/27(日) 21:01:29.29
>>504

平行線というか、同じ直線上にあるから、無限でもあるし、存在しないとも言える。
普通存在しないと考える。
どうしても必要なら配列をラムダ化して遅延評価を使う。
ま、直線自体はベクトルだしな。


506 :仕様書無しさん:2011/02/27(日) 21:14:34.96
だから、同次座標使えと。

507 :仕様書無しさん:2011/02/27(日) 22:05:23.28
で、その話と例外と、どう関連付けたいんだ?

508 :仕様書無しさん:2011/02/27(日) 22:22:18.71
いっつも話が横道にそれておかしな事になるよなw

509 :495:2011/02/27(日) 22:54:55.86
まだあのアホな話題続けてたのね
答えありきで例題(笑)を考えて、お前ら答えてみろって言ってみたものの即スレチだとあしらわれ、
相手にされなかったら勝利宣言だしてしたり顔…。痛い子のテンプレートみたいだなw

戻り値の型についても、例外にする条件についても、事前に儲ける必要のある制約次第ってだけ。
だから情報の足りない提示された前提だけじゃ、プログラム上での表現方法なんていくらでも想定できる。
問題不備な時点で、必要な情報を表せる型を返す以上の具体的な表現には意味なんかねーよ。
むしろ配列が模範解答とか言っちゃう時点で…w

510 :仕様書無しさん:2011/02/27(日) 23:01:18.85
答えありきで、って部分は訂正
具体例に落とすには、まず何を求めるかを明確にする必要があるのに
それをやらずに答えてみろっていう問題が問題だっていう話

仕様を提案しながら固めるのが目的のスレじゃねーんだから、
どっちにしてもこのスレで広がる話題ではないけどな

511 :仕様書無しさん:2011/02/27(日) 23:12:04.90
あのアホ、ここがプログラマー板だって事忘れて、プログラマを貶める発言とかしてるからな。

512 :仕様書無しさん:2011/02/28(月) 00:56:48.12
それよりも例外の話しようぜ

513 :仕様書無しさん:2011/02/28(月) 01:49:59.97
>>501
数学的に0除算と同じ例外扱いだったと思うけど
何を根拠に例外じゃないと言いはってんだろ?

514 :仕様書無しさん:2011/02/28(月) 03:13:18.01
人のフリみてなんとやら
何を根拠に〜っていうのは、数学的に0除算〜と思うけど、つー部分にも当てはまるけどな
あ、ソースはこれだ、とかいった話は別に続けなくていいよ。スレ違いだから

515 :仕様書無しさん:2011/02/28(月) 12:37:46.51
>>513
「0除算」と「解なし」が同レベルとでも思っているのか?
「解なし」は立派な答えだ、中学生でも分かることだろう。

516 :仕様書無しさん:2011/02/28(月) 13:12:36.23
たしかにな、「解なし」はもちろん例外でも無いしエラーですら無い。
通常の答えだ、このスレにはまったく関係ない。

まっ、問題を出した人間が中学生の数学も分からない
例外的人間だと言う事は分かるがw

517 :仕様書無しさん:2011/02/28(月) 14:22:34.10
正しい例外の使い方をしめしてください

518 :仕様書無しさん:2011/02/28(月) 14:25:31.25
>>517 http://www.parashift.com/c++-faq/exceptions.html

519 :仕様書無しさん:2011/02/28(月) 23:36:05.70
>>518
C言語と日本語でお願いします。

520 :仕様書無しさん:2011/03/01(火) 00:12:36.35
おいちょっとまて

521 :仕様書無しさん:2011/03/01(火) 01:21:57.72
基本の使い方でなく、業務的に入り組んだサンプルがほしいです

522 :仕様書無しさん:2011/03/01(火) 02:19:58.69
>>521 http://www.google.com/codesearch?q=lang%3Ac%2B%2B+catch

523 :仕様書無しさん:2011/03/01(火) 19:36:03.24
コードだけ示されてもなぁ・・・

何をどうしたいために、どういう風に実装してるか、なぜ、それで
なければいけないか、とかの解説付きでないと意味ねーよ。

524 :仕様書無しさん:2011/03/01(火) 20:24:11.07
>>522
Javaでお願いします。


525 :仕様書無しさん:2011/03/01(火) 21:19:36.54
整数型や文字列へのポインタを返す例外をキャッチしたら、誰から
投げられたかが分かるんだw

どんな原因で起きたかが分かるんだwww


投げられた整数値に、そういう事が分かる番号割り振ってるんだw

文字列に、そういう意味のトークン繋げてるんだwwwwwwwwwwwwwwww

526 :仕様書無しさん:2011/03/01(火) 21:35:20.20
捕まえたとこで処理できない場合
ラップして上に投げるのはごく普通のこと

例外クラスでググれ

527 :仕様書無しさん:2011/03/01(火) 21:37:13.04
そんな事言ってないだろ

528 :仕様書無しさん:2011/03/01(火) 23:07:15.41
>>525
> 整数型や文字列へのポインタを返す例外をキャッチしたら、誰から
> 投げられたかが分かるんだw

なんのために、誰から投げられてか
知りたいのかわかんないんだけど?

誰から投げられたかなんてどうでもよくね?
関数の中の誰かってだけわかれば
それで十分だと思うが?


529 :仕様書無しさん:2011/03/01(火) 23:27:51.55
func1();
func2();
func3();
のどれで例外が発生したかを区別する必要があることはよくあるな。

530 :仕様書無しさん:2011/03/01(火) 23:41:57.58
そこで継承だろ

531 :仕様書無しさん:2011/03/02(水) 01:01:26.69
発生元の区別が必要ならcatch後の処理も違うんだから、まずtry-catch句を分けろよ

532 :仕様書無しさん:2011/03/02(水) 04:42:53.73
またそこへ戻るのかw

533 :仕様書無しさん:2011/03/02(水) 15:59:59.50
戻るも何も例外の思想を理解してないだけじゃん

534 :仕様書無しさん:2011/03/02(水) 20:41:12.37
戻るっていうか基本だわなw
理解してない奴は最初でtry最後でcatchしてそれで全てを知ってると思ってるけど

535 :仕様書無しさん:2011/03/02(水) 21:02:48.71
無秩序に例外使いまくってるアホは黙ればいいのに。それ、オマエの都合
だけで書いてるから、他の誰も理解したがらないわ。

536 :仕様書無しさん:2011/03/02(水) 21:50:48.54
と、簡単な仕組みすら理解する能力のない馬鹿が無能を曝け出していましたとさ。

537 :仕様書無しさん:2011/03/02(水) 21:52:13.58
>>529
> のどれで例外が発生したかを区別する必要があることはよくあるな。

重要なのは、区別して何をするかなんだが
「区別する必要がある」のはお前の設計がおかしいからじゃないのか?



538 :仕様書無しさん:2011/03/02(水) 22:07:59.22
人に迷惑を掛けなければ、どんな例外処理をしてもいいと思うが
俺の職場には共通モジュールで、エラー処理を例外クラスにしている馬鹿がいる。
実行EXEでは構わないが、デバック中にエラーごとに例外が
IDEに飛んで来て実行が中断し、とても迷惑している。

本人は自慢げにエラーを例外で処理していると言っているが
単に技術や知識が乏しい迷惑な奴だ。

539 :仕様書無しさん:2011/03/02(水) 22:14:32.20
例えばこういうの?
http://d.hatena.ne.jp/higayasuo/20091111/1257905482
try {
    ds.get(key);
    // 既にエントリが存在する
    return false;
  } catch (EntityNotFoundException e) {
    // 見つからなかったのでputする
    Entity entity = new Entity(key);
    ds.put(tx, entity);
    // ユニークな値が確保できた
    return true;
  }

540 :仕様書無しさん:2011/03/02(水) 22:34:09.60
継承を使えばいいだろ(キリッ


上司に異常を報告しても、「なんとかしろ」と言われるだけ。

で、助教に応じて「なんとかする」という仮想メソッドを実行する。

だったら報告せずに、内々で「何とかする」方がマシ。

541 :仕様書無しさん:2011/03/02(水) 22:34:36.96
× 助教
○ 状況

542 :仕様書無しさん:2011/03/02(水) 22:43:49.43
いきなりどうした

543 :仕様書無しさん:2011/03/02(水) 22:48:56.28
>>538
catchしてない例外ならバグじゃねーの

544 :仕様書無しさん:2011/03/02(水) 23:11:34.16
>>537
仕事では既に決まってる要求仕様は実現しないといけないからねぇ。

545 :仕様書無しさん:2011/03/02(水) 23:14:12.39
>>538
> 実行EXEでは構わないが、デバック中にエラーごとに例外が
> IDEに飛んで来て実行が中断し、とても迷惑している。

お前のほうが知識に乏しいんじゃね?

例外でIDEが中断しないように設定すれば済む話。


546 :仕様書無しさん:2011/03/02(水) 23:15:12.30
>>544
だからさぁ。その要求仕様がなにかって
聞いてるんだけど。

ごまかしてるよね?ね?

547 :仕様書無しさん:2011/03/02(水) 23:18:57.87
>>540

例外ではなくビジネスマナーの話をすると、
自分で解決できない問題は
すぐに上司に伝えるべきだ。

548 :仕様書無しさん:2011/03/02(水) 23:22:58.33
自分で解決できないからって
上司に相談するやつは無能。
それが許されるのは新人だけ。

549 :仕様書無しさん:2011/03/02(水) 23:25:01.14
ホウレンソウ

550 :仕様書無しさん:2011/03/02(水) 23:31:15.62
まぁクサレ上司も多いからな。

551 :仕様書無しさん:2011/03/02(水) 23:58:13.44
上司クラスが腐ってるアプリケーションは稀に良くある
つぎはぎつぎはぎしてきたせいで今更改修するわけにもいかない状態で
アホみたいなことしないといけない、泥沼コース

そういや、んなとこだと、まともにtry-catchできてるようなのは一度も見たことねーなw

552 :仕様書無しさん:2011/03/03(木) 01:17:36.14
上司が腐ってれば、
何を使っても同じことだろうさ
ということでこの話題は終わり。

例外は素晴らしいね。

553 :仕様書無しさん:2011/03/03(木) 01:24:09.73
>>543
>catchしてない例外ならバグじゃねーの
例外処理はしているが、その前にIDEが一度中断するから
たちが悪い。

>>545
>お前のほうが知識に乏しいんじゃね?
>例外でIDEが中断しないように設定すれば済む話。
お前みたいな中途半端な知識しかもってない人間が駄目なんだよな。
もちろん設定出来るものはしているが、出来ないケースもあるんだよ。
知識が無い奴は黙ってろよ。

554 :仕様書無しさん:2011/03/03(木) 01:36:09.98
> もちろん設定出来るものはしているが、出来ないケースもあるんだよ。

できないケースってなに?

IDEとできないケースを言ってみ。



555 :仕様書無しさん:2011/03/03(木) 02:06:10.30
もう寝たのか?答えられないのか?

IDEで例外発生時に止めることができるのなら、
それをOFFにすることは簡単なはずで
それをサポートしてなんてあるはずないんだが。

556 :仕様書無しさん:2011/03/03(木) 02:09:35.63
>>553
それはIDEの設定が悪いだけじゃん
VSだっけ?最近使ってないから忘れたけど

557 :仕様書無しさん:2011/03/03(木) 02:14:11.41
>>554
>できないケースってなに?
>IDEとできないケースを言ってみ。
そんなのも分からないのか?
知識も経験も無いんだな。

>>556
>それはIDEの設定が悪いだけじゃん
>VSだっけ?最近使ってないから忘れたけど
お前も、知識・経験が無いんだな。

ボクちゃんたち頑張って経験積もうね。

558 :仕様書無しさん:2011/03/03(木) 02:30:33.15
裸の王様はじまったな

559 :仕様書無しさん:2011/03/03(木) 02:38:02.49
ここまで絵に書いたようなテンプレ回答返すとか、また例の馬鹿が戻ってきたかw
例外の否定のときと同じで、答えれないから「知らないの?」って質問を質問で返すんだよな

560 :仕様書無しさん:2011/03/03(木) 06:40:31.22
IOExceptionとか滅多に起こらない障害の例外処理はめんどいでござる
例外じゃなくてエラーでいいのに

561 :仕様書無しさん:2011/03/03(木) 06:49:52.71
>>560
検査例外なのが悪いだけで、例外は悪くないんじゃない?

562 :仕様書無しさん:2011/03/03(木) 07:47:59.89
>>560
めったに起こらないだけで、
全く起こらないわけじゃないだろ?

ならエラーチェックしないとだめだろ。

563 :仕様書無しさん:2011/03/03(木) 10:38:20.49
ここの例外馬鹿はエラーチェックはしないポリシーですから

564 :仕様書無しさん:2011/03/03(木) 10:40:37.07
例外馬鹿の特徴
・設計関連の知識はゼロ
・例外は自分の書いたコードがうまくうごくまでのデバッグツールとして利用
(つまり、設計書からまたは頭で描いたコードをそのまま落として実行できない
すわなち、馬鹿)
・スクリプト言語しか使えない
(つまりコンパイルエラーとかは経験がないので、例外だけを語れるようになった)

565 :仕様書無しさん:2011/03/03(木) 11:31:17.91
>>563
>ここの例外馬鹿はエラーチェックはしないポリシーですから
嘘つけw

566 :仕様書無しさん:2011/03/03(木) 13:28:38.08
滅多に起こらないからこそ例外なのである

567 :仕様書無しさん:2011/03/03(木) 13:40:54.89
>>565
エラーチェックを例外処理にしているだろ。
だから本当じゃんw

568 :仕様書無しさん:2011/03/03(木) 13:53:54.95
>>567
あぁ、「自分では」エラーチェックしないってことか。それはそうだな。

569 :568:2011/03/03(木) 13:54:58.02
いや待て。例外を投げるときにはチェックするぞ。やっぱりおかしいな。

570 :仕様書無しさん:2011/03/03(木) 15:13:09.36
>>560は、いっそアプリが落ちていいよと言ってる気がするのは俺だけ?

571 :仕様書無しさん:2011/03/03(木) 15:14:13.88
エラー処理が面倒だからとか、滅多に起こらないからとか
誰かが何とかしてくれるだろう的な例外が一番嫌い

ずばり、設計に無い例外を投げるのはバグです

572 :仕様書無しさん:2011/03/03(木) 20:28:27.65
>上司クラスが腐ってるアプリケーションは稀に良くある

稀に良くある・・・ どっちやねん(´・ω・`)

573 :仕様書無しさん:2011/03/03(木) 20:36:19.59
もう何言っても言い負かされるから、「例外馬鹿め!」って喚き散らすしかできなくなった、
いつもの例外すら理解できない馬鹿がまた沸いてるなw

>>571
エラー処理が面倒だから無視されるより、処理してなかったら不具合がすぐそこで分かるほうがマシ
例外じゃなかった場合、その不正値が無視されてても誰もわからないままになって
そいつがとんでもないところでやらかして、データ全破壊とかするかも知れんしな

574 :仕様書無しさん:2011/03/03(木) 20:47:07.47
どっちかつーと設計も開発も糞な奴は例外なく「例外」を理解できてない、だわな。

いつものryは、例外をデバッグツール()とか、また頭の悪いこと言ってるけど、
それは例外どころか、デバッガのアタッチすらできない正真正銘の無能が、
Alertデバッグの代わりに例外でブレークしてるつーアホ話だろ。
そんな使い方する馬鹿が例外を語れると思ってるあたり、相変わらず頭悪いな。

575 :仕様書無しさん:2011/03/03(木) 20:49:46.14
>>574
お前、いつも人格否定しかできないじゃん

576 :仕様書無しさん:2011/03/03(木) 21:03:53.01
図星だったらしい。

577 :仕様書無しさん:2011/03/03(木) 21:07:58.84
即レスするほど張り付いてんのか

578 :仕様書無しさん:2011/03/03(木) 21:29:38.69
>>573
だからと言って、例外最高!って叫ぶ気にはならない
不正値を無視するコードからは例外さえ飛んでこないよ…

579 :仕様書無しさん:2011/03/03(木) 21:31:38.80
製作者が不正だと思い込んだものに対してはやたらと厳しいのに
そもそも仕様書にはどう書いてあるんだよ?
っていうところがあいまいになるんだよなw

580 :仕様書無しさん:2011/03/03(木) 21:43:53.82
最下流工程にしかかかわらせてもらえないコーダーは悲しいねー

581 :仕様書無しさん:2011/03/03(木) 22:28:24.24
例外の場合エラーチェックをしないじゃなくて
デフォルトのエラーチェックに任せるって感じだよな。

戻り値の場合は、本当にエラーチェックをしないだから
だめなんだが。言うまでもなかろう。

582 :仕様書無しさん:2011/03/03(木) 22:41:02.73
検査例外万歳。
わりとマジ。

583 :仕様書無しさん:2011/03/03(木) 22:46:22.62
>>582
1000箇所で呼び出したら1000回例外チェックするんですね?
同僚から早く死ねって言われてることに気づいてください

584 :仕様書無しさん:2011/03/03(木) 22:48:35.17
検査例外でよかったことなんてあるの?

try {
 ・・・
} catch(検査例外) {
  同じコード
} catch(RuntimeExcepiton e) {
  同じコード
}

結局こんなふうに重複コードを書いて終わりな気がするんだが?

585 :仕様書無しさん:2011/03/03(木) 22:53:22.97
そろそろ釣り宣言

586 :仕様書無しさん:2011/03/03(木) 23:24:34.51
>>583
検査例外じゃなくてもやるだろ

587 :仕様書無しさん:2011/03/03(木) 23:40:00.90
>>586
やんねーよタリーな

588 :仕様書無しさん:2011/03/04(金) 00:13:56.46
例外ってチェックするもんじゃねーだろ

589 :仕様書無しさん:2011/03/04(金) 00:16:45.75
検査例外はプロジェクト全体がちゃんと正しく使ってるならヒューマンエラーの回避にはなる
ただし馬鹿が一人混じるだけで崩壊する

「コンパイル通らない!」
「そうか、意味はわからないけど throws Exception ってつければ問題ないのか」
こんなアホが現実に存在する不思議

590 :仕様書無しさん:2011/03/04(金) 01:12:13.42
つまり、例外は使い物にならないって事ですね。わかります。

591 :仕様書無しさん:2011/03/04(金) 08:35:49.08
アホがいないプロジェクトなら、戻り値でもやっていけるさ

592 :仕様書無しさん:2011/03/04(金) 09:35:46.29
結局アホが居ると何やってもダメという当たり障りのない結論に

593 :仕様書無しさん:2011/03/04(金) 18:07:31.37
同僚の顔がキモすぎて仕事に集中できない。
同性の顔なんて気にならねーって思ってたけど全然違うんだな

594 :仕様書無しさん:2011/03/04(金) 22:04:44.72
それは鏡だ

595 :おじゃばさま:2011/03/05(土) 08:03:37.02
戻り値を否定するのか。
ケースによっては戻り値でswitch文の多重分岐を起動するトリガにするんだけどな
ここの例外馬鹿は多重分岐のトリガも例外でしょりするのかな

596 :おじゃばさま:2011/03/05(土) 08:55:40.76
>デバッガのアタッチ

あんな素人しか使わない仕組みでデバッグしてるのか?

597 :おじゃばさま:2011/03/05(土) 08:59:18.27
プロセスのアタッチ手法はIDEを二つ起動してPIDにアタッチしてデバッグするのだが
それりゃ、かったるい事このうえない。
問題が発生している箇所をダンプすれば一発でわかるのになあ。
つまり、例外馬鹿は「そもそもどこで不具合が発生したか」すらわからない馬鹿

598 :仕様書無しさん:2011/03/05(土) 09:07:31.86
なんでIDEを二つ起動するんだ

599 :仕様書無しさん:2011/03/05(土) 09:08:10.57
>>595
なんでそんな曲解するの?

関数の戻り値に値とエラー値を混ぜるなって話。
たとえば、プラスだったら○○という意味で
マイナスならエラーとかいうふうに混ぜるなということ。

エラー値を混ぜるところは、例外でやれという話。


600 :仕様書無しさん:2011/03/05(土) 09:08:56.03
> 問題が発生している箇所をダンプすれば一発でわかるのになあ。

問題が発生ている箇所をダンプしなくても
一発でわかるのが例外。


601 :おじゃばさま:2011/03/05(土) 09:54:24.05
>>599
君は経験がないようだね。多重分岐するための値とエラー値と混ざるよ
それは当然でしょう。多重分岐処理判断のメソッドで例外捕獲したとしても
リターンした上位のcaseでdefaulでエラー処理する必要があるだろう
正常値とエラー値とまざるときはまざらざるをえないんだよ。馬鹿だな
これらはサーバ系の開発の話だけどね、クライアントスクリプト言語糞アプリは
エラーが起こってもスクリプト例外で画面表示されるだけだからべつにどうでも
いいかもしれんがね

602 :仕様書無しさん:2011/03/05(土) 10:01:06.31
>>601
日本語で頼む

603 :仕様書無しさん:2011/03/05(土) 10:03:57.40
俺は成功失敗のある関数の戻り値は可能な限りbool派

604 :仕様書無しさん:2011/03/05(土) 10:10:04.71
せめてちょっとは文体を似せる努力ぐらいしろよ…

605 :おじゃばさま:2011/03/05(土) 10:23:38.22
>>603
BOOLですべてこと足りればそれでいいと思うが
たとえばファイルを読み込んでクラアントブラウザにコンテンツを送信する
HTTPサーバだと、読み込んだファイルのサイズをContent-Length:にセットしなければ
ならない。BOOLの場合だと if (FALSE) content_len = 0;
とか上位でコンテントレングスのエラー時のコントロールが必要になってしまう

606 :おじゃばさま:2011/03/05(土) 10:28:48.20
>>598
クライアントアプリケーションではひとつが主流だな。つまり君は
エラー処理をいいかげんに済ませても問題ない糞クライアントアプリしか
組めないということだな

607 :仕様書無しさん:2011/03/05(土) 10:29:11.36
>>605
それが必要なら必要な関数を作るしかないな
引数でやる
ただし、それを必要としてない場合はそれをアピールしたいから
それを取得していない関数もそれはそれでほしいんだよね

608 :おじゃばさま:2011/03/05(土) 10:31:06.08
>>607
それとかあれとかナニがでは「コードレビューもできんやつだな」と烙印をおされるぞ

609 :仕様書無しさん:2011/03/05(土) 11:06:55.39
>>605
content_len = 0なんかいらんよ。
固定のエラーページ送信をやって、
それも失敗したら埋め込みの500だ。

もうちょっとマシな例を持って来い。

610 :おじゃばさま:2011/03/05(土) 11:19:18.77
>>609って本当に馬鹿がヅラーと連なったようなやつだね
埋め込みの500番のエラーページもブラウザに表示される分のContent-Lengthが
セットされているんだよ。内部的に読み込めない->エラー->content_len=0
をたとえばエラーの判断として HTTPヘッダをつくり、エラー表示分のコンテントレングス
をヘッダにのせるんだよ。もっと深いとこまで考えてみろよ。むりか、所詮ブラウザで
動作するスクリプターだからなあ

611 :仕様書無しさん:2011/03/05(土) 11:28:17.25
そうなんだよね。
エラーが起きたとき、そのエラーが起きた情報ってのが必要になる。
その情報は値の集合体だからboolやintじゃ足りない。

じゃあ構造体を使う。どんな場合でも同じやり方が出来るように
引数で値を返す。とかいう決まりを作っていったら
そこでふと考えるべきなんだ。

そうやって考えて作ったものが、例外なんだと。

612 :仕様書無しさん:2011/03/05(土) 11:34:15.47
エラー内容を1ファイルのログからすべて推測できるようにするべきだろうな

613 :仕様書無しさん:2011/03/05(土) 11:36:35.16
>>612
順番が間違ってるぞ。

例外の内容を、ログに書きだすんだよ。

614 :おじゃばさま:2011/03/05(土) 11:42:28.55
もう馬鹿==>>609の反論はないのか、情けないやつだな

615 :おじゃばさま:2011/03/05(土) 11:43:54.63
まあ、所詮例外例外って騒ぐ馬鹿は正常系のインプリメントもまともに
できないから騒いでいるだけなんだろうな

616 :仕様書無しさん:2011/03/05(土) 11:59:48.46
それ、逆だと思うよw

617 :おじゃばさま:2011/03/05(土) 12:09:09.25
>>611
戻り値のエラー情報を構造体を使って共通化する例を考えてみた
よければ添削してくれないか

どんなデータタイプでもvoid *が引き受ける、セットされるデータタイプの判断は
errTypeの値で判断する void *errには構造体でも配列のアドレスでもなんでもオッケー
ただし明示的なキャストが必要になるのでこれもサーバ系開発向きかな
typedef struct __tg_errStat{
int id; //スレッドidなどの識別用、必要ないなら削除してくれ
 BOOL except; //TRUEならばエラー、冗長なら削除してくれ
int errType; //セットされたエラー情報のデータ型判断変数 (enum化してくれ、またはenumのメンバにしてしまえ)
void *err;
}ERR_STAT;


プロトタイプ
ERR_STAT hoge(void);
ERR_STAT hoge(int); .....


618 :おじゃばさま:2011/03/05(土) 12:11:49.45
>>616 それとかあれとかどれとか言うやつはこの業界ではクズな定説

619 :仕様書無しさん:2011/03/05(土) 12:18:43.67
>>617
間違ったキャストをしたら
落ちずにエラーが出るようにしてください。
また関数定義だけではなく実装もしてください。

620 :おじゃばさま:2011/03/05(土) 12:21:04.48
>>619
バッファオーバーフローやアドレスセットはコーディングするプログラマの責任範囲
だから「間違えないでインプリメントする」が基本

ここはあえて>>619がしてみてくれないか?

621 :仕様書無しさん:2011/03/05(土) 12:22:37.81
> ただし明示的なキャストが必要になるのでこれもサーバ系開発向きかな

意味がわからんw


622 :おじゃばさま:2011/03/05(土) 12:23:28.99
プロトタイプはこのほうがいいかも、まあ構造体のコピーでもいいけど
無駄だよな、参照のほうが合理的だと思う

ERR_STAT* hoge(void);
ERR_STAT* hoge(int); .....


623 :仕様書無しさん:2011/03/05(土) 12:24:01.59
>>620
> バッファオーバーフローやアドレスセットはコーディングするプログラマの責任範囲
> だから「間違えないでインプリメントする」が基本

間違えたときにその原因がすぐに分かるようにするのも
プログラマの責任の範囲だよ。

> ここはあえて>>619がしてみてくれないか?
例外を使えばできるけど、
例外を使わないなら無理。


624 :おじゃばさま:2011/03/05(土) 12:24:14.78
>>621

へっ? void*の扱い知らない? か・・・

625 :仕様書無しさん:2011/03/05(土) 12:25:19.89
>>624
明示的なキャストが必要だと、
なぜサーバー向きになるのかがわからんと言ってるの。

626 :仕様書無しさん:2011/03/05(土) 12:25:26.58
>>610
言語によるが、例えば静的に存在する文字列を
acceptしたTCPソケットに直接writeすりゃ良い。

要は最悪ケースのエラーページは下位層に
ハードコーディングしときゃ良いんだよ。
何で上位がそんなモンを設定する必要がある。

627 :仕様書無しさん:2011/03/05(土) 12:27:16.78
ダウンキャストとアップキャストの違い知ってる?

void*を使うのは危険だよね。


628 :おじゃばさま:2011/03/05(土) 12:28:12.55
つうか、仕様どおりの実装をしたとき、おのずとエラーの種別
エラー内容を表示するためのデータ型とか固定になると思うのだが?
だから「原因」などわからなくともインプリメントを間違えばコードを書いている
ときにすぐ分かることだと思うけど。

間違えたときの原因なんて例外を使わなくともわかるだろう?
お前さんキングオブ馬鹿だな

629 :仕様書無しさん:2011/03/05(土) 12:30:36.90
> 間違えたときの原因なんて例外を使わなくともわかるだろう?

わかるかわからないかの話をしてるんじゃないよ。
わかるまでにかかる時間の話。

例外を使っていれば、エラーが出たらすぐに分かる。
原因となった関数とか行番号とかも表示されるから。



630 :おじゃばさま:2011/03/05(土) 12:33:13.60
>>627
キングオブ馬鹿さん、それはオブジェクトのキャストだろ
参照のアドレスをセットするだけだから、コンパイラにはデータの
sizeofを知らせてやる必要のあるキャストだ
ポインタアドレスはsizeofプロセッサ固定だからな

631 :おじゃばさま:2011/03/05(土) 12:34:35.59
>>629
だから >>628で言っているように、そんなくだらない間違いは即わかるのが
職業プログラマだろ、お前の言っているのは「素人がコードが書けないから
例外でデバッグを支援してもらいたい」としか聞こえん

632 :仕様書無しさん:2011/03/05(土) 12:35:05.39
どうも例外を使わないやつって、
発想がプログラムを作ってるだけな気がするな。
自分が今担当しているプログラムだけが動けばそれでいい感じ

例外を使う人って、プログラム単体だけではなく
プログラムを使って構成されたシステム全体が
統一された方法で正しく動くってことまで考えてる。
だから、どちらが安全かとかどちらが開発効率がいいかとか
どちらが汎用的に使える仕組みであるかとか設計とか
そういう高レベルなところから物事を見てる。

考えてる範囲が大きく違いすぎるよね。


633 :仕様書無しさん:2011/03/05(土) 12:38:32.06
>>631
例外でデバッグを支援してもらうって発想が
お前が例外に使われてるだけのやつだって示してるよ。

例外はな道具だ。俺が例外を使って
開発を楽にするようにコーディングするんだよ。

開発を楽にするための道具はなんでも使うよ。
例外でもデバッガでもユニットテストでも。

でもお前は、それらを使ったら
コードを書けないから道具を使うんだろと言うんだろ?
アホじゃね?

634 :おじゃばさま:2011/03/05(土) 12:56:02.34
またつっこみどころ満載な>>626が書かれていたな
しかし、いくら話してもHTTPDの仕様すらわかっていない様だから
もう話しても無駄だと確信した

635 :仕様書無しさん:2011/03/05(土) 13:02:50.26
話すこと(反論)がないなら、レスしなければいいじゃんw

636 :仕様書無しさん:2011/03/05(土) 14:12:02.01
いやいや、仕様が全く理解できない馬鹿にいくらナニをいっても無駄ということ

637 :仕様書無しさん:2011/03/05(土) 14:16:21.32
おじゃばはスレの流れイマイチ分かってないのか知らんけど
大抵は、例外否定派は全部の例外をなくせ、一切例外は発生させるな、戻り値で返せって主張してて
例外肯定派は、戻り値では出来ないことでも出来るしケースによるだろって感じだぞ

処理しきれない状況になって例外が発生した場合に、
エラーを示す値を戻り値で返す場合、
意図しないエラー無視が出来てしまうから、極力控えるべきだと思うよ
例外を投げるのは、異常系とかの考慮が足りてない人に向けた対策みたいなもんだしな

638 :仕様書無しさん:2011/03/05(土) 14:20:09.72
>>631
職業マは、仕事以上の勉強は絶対にしないし、仕事中しかコーディングしないし、
行き当たりばったりでスパゲッティな打開策を積み重ねるような奴のことだぞ。
おじゃばさまってのがなんなのかは俺は知らんが、見てるとなんかいろいろ勘違いしてそう。
空気は読めないけど、適当な敵を作って議論もどきをするのが趣味な人なん?

639 :仕様書無しさん:2011/03/05(土) 14:20:38.59
話はすごく単純で
戻り値に、二種類の違った値を入れるなというだけのこと。

変数に二種類の違った値を入れたら
どうなるかぐらいわかるだろう。

640 :仕様書無しさん:2011/03/05(土) 14:22:10.73
自分でいろんな言語を使おうという人なら、
例外がある言語を使ったことはあるはず。

COBOLとC以外でメジャーな言語なら
例外あるからね。

641 :仕様書無しさん:2011/03/05(土) 14:23:06.32
>>637
で、その対策のおかげでバグが露呈してしまい、修正が必要になって
アホコード書いてた奴が「例外うぜぇ」って叫んでるんだよなw
しっかり役に立ってんじゃねーかwww

642 :仕様書無しさん:2011/03/05(土) 14:23:28.58
>>638
今いるのは、偽おじゃばだよ。

643 :仕様書無しさん:2011/03/05(土) 14:26:58.49
>>642
あれ、いくらなんでもアホ過ぎるとはおもったけど、いつものアホだったってオチ?

644 :643:2011/03/05(土) 14:31:14.10
ああ本当だ。全然違うわw

645 :仕様書無しさん:2011/03/05(土) 14:31:22.71
どっちでもいいが、いつもアホ過ぎぐらいのアホだよ。あいつは。


646 :仕様書無しさん:2011/03/05(土) 14:33:17.12
あ、もちろん例外使うなーって叫んでる何時ものアホのことです。

647 :おじゃばさま:2011/03/05(土) 14:50:47.49
>>638
日本のマに残念率が高いのは、これが原因。
だが、お前も自分じゃ勉強してなさそうなのに、他人のことに腹立ててる時点で大したレベルじゃないな。

638自身、お前の言う職業マじゃねーの?

648 :仕様書無しさん:2011/03/05(土) 15:00:35.74
苦しいな

649 :仕様書無しさん:2011/03/05(土) 15:07:45.02
なら病院行け

650 :仕様書無しさん:2011/03/05(土) 15:29:56.18
いろいろ言われてるのに、スレと関係ないどうでもいいところにしかレス返せない時点で

651 :仕様書無しさん:2011/03/05(土) 15:56:34.00
ホンモノはもっとこうムカツキ感が高い。まわりくどい感じとか。
思わずこの野郎、と突っ込みたくなる不快さに欠けるねニセモノは。
バカをするにも芸がないとダメだという見本。

652 :仕様書無しさん:2011/03/05(土) 16:12:32.02
素で馬鹿な奴はこんなもんが限界だろうな。

653 :仕様書無しさん:2011/03/05(土) 16:45:30.32
残念ながらおじゃばは素で馬鹿

654 :仕様書無しさん:2011/03/05(土) 16:52:21.70
>>639
例外とは関係ないけどね。

655 :仕様書無しさん:2011/03/05(土) 18:20:54.94
このコテってここまで馬鹿だったっけ?
発言もキレがないし前より劣化してないか?

656 :仕様書無しさん:2011/03/05(土) 19:22:43.70
別な意味でバカさが足りない。もっとこうネチネチしてないと。

657 :仕様書無しさん:2011/03/05(土) 20:15:34.95
言葉尻捉えてるだけのアホだから、テキトーにからかってやればすぐにボロを出すのに?

658 :仕様書無しさん:2011/03/05(土) 20:25:36.37
>>654
戻り値でエラーを返す方法とは関係あるよ。

659 :おじゃばさま:2011/03/05(土) 22:37:20.88
馬鹿ばっかだな。
戻り値はエラーを返すためにあるものじゃない。
あくまでも仕様上定められた値を返すためにある。そこを理解していないと積むので注意。
素人にはこれが分からない。


仕様上返すべき値であれば、それが何であれ戻り値にすべきだが例えば、
ojava(object o) {
  // oにnullが入ってきた。
}

という状況で仕様上oは非nullであると定められていたのならば、
ojava( object o {
 if (o == null) {
  NullZamasuwayoException("o");
 }
}
とでもやって、oがnullであることを高らかに宣言し、例外をスローしなければならない。
要するに仕様にあるべきなのが戻り値で、あってはならないのが例外。
仕様や設計が決められないここの連中にはレベルが高すぎて一生ついてこれないだろうけどな。
そもそも、お前らが設計をやること自体がソフトウェア工学に対する冒涜にも値するわけで……

660 :仕様書無しさん:2011/03/05(土) 22:44:37.95
おや、本物のおじゃばが出てきたw

戻り値厨の偽おじゃばどうするよw

661 :仕様書無しさん:2011/03/06(日) 08:25:22.48
つまらん自演。そーゆーとこがニセモノはなんというか軽いな。
ホンモノは堂々と自信を持ってバカだぞ。そんな小賢しい学習能力などない。

662 :おじゃばさま:2011/03/06(日) 08:26:36.83
うはうは

663 :仕様書無しさん:2011/03/06(日) 13:42:59.54
例外を使いこなせないというよりは
例外ハンドラの奴隷というほうが正しいと思うが
ものによってtyrブロックで囲まないとコンパイルエラーになるしな

664 :仕様書無しさん:2011/03/06(日) 14:10:46.60
理解できないお馬鹿さんには翻弄されてる気分になるのか
ただの言語機能の一つでしかないのにな

665 :仕様書無しさん:2011/03/06(日) 14:59:04.59
翻弄されていることに気づかないのも問題だけどな。

666 :仕様書無しさん:2011/03/06(日) 15:10:10.03
流石にだいぶ落ち着いてきたな。
いつもの例外全否定のアホも、最近は叩かれないようにって、
どっちつかずな感じの短文レスばっかりになったし、
例外自体は普通の仕組みだから、今更これといって広がるような話題もないしで、
当たり前っちゃ当たり前だろうけど、一時期の勢いが嘘のようだ…(w

667 :仕様書無しさん:2011/03/06(日) 20:10:21.44
一時期の勢いは、
例外を理解出来ないバカのせいだ。

たぶんプログラムの世界において
できると自信があったのだろう。
だが井の中の蛙であったことを知って
逆上したのだろう。

668 :仕様書無しさん:2011/03/06(日) 20:36:40.62
つまらん自演。

669 :仕様書無しさん:2011/03/06(日) 20:43:34.91
↑もうこんなのばっかりになってきたねw

670 :仕様書無しさん:2011/03/06(日) 22:43:48.98
>>668
>>668

671 :おじゃばさま:2011/03/07(月) 02:14:25.50
いやね、ちょっと忙しくなっちゃったんだよ
暇になったら、例外の内部コードをさらして、叩ききってあげるから
待っててね

672 :仕様書無しさん:2011/03/07(月) 18:50:48.37
例外を全否定してるヤツなんていたか?

673 :仕様書無しさん:2011/03/07(月) 19:55:44.50
いねーよ。どっちのバカも自演だし。

674 :仕様書無しさん:2011/03/07(月) 20:34:09.67
なんか例外厨の粘り勝ちみたいになってきたな。
正論を書いても奴も基地外にはかなわないか。

これがネットだけじゃなく現実の世界でも
基地外みたいに声が大きい方が正しいとかなるから怖いよな。

675 :仕様書無しさん:2011/03/07(月) 20:56:20.93
>>674
つまりどういう事?

世の中の正しいことは
全部基地外が考えたということ?

676 :仕様書無しさん:2011/03/07(月) 21:54:27.93
ここは、
例外を理解できなかったせいで、方々からフルボッコにされたおっさんが
どうにかして自分を叩いてた奴が悪いような雰囲気になるよう
試行錯誤しながら誘導を試みるためのスレッドになりました

もうそれくらいしかできることがないのです。いじめないであげてください(うω;`)

677 :仕様書無しさん:2011/03/07(月) 22:30:17.18
え、なに? 俺が例外厨煽らないといけない雰囲気なの? なの?

678 :仕様書無しさん:2011/03/08(火) 00:02:36.63
>>675
そうやって絡んで来るから
みんな「お前が正しいと認めてやるから、絡んでくるな」的になるんだよね。
やっぱ基地外が最強かだね。

679 :仕様書無しさん:2011/03/08(火) 00:22:44.31
テンパるのは結構だがせめて日本語を書け

680 :仕様書無しさん:2011/03/08(火) 00:54:18.39
うゎ〜、俺にも絡んできたw
あんたが正しいよ、確かに誤記があるね。
でも相手に「せめて日本語を書け」と書くなら、せめて句読点は書こうねw

681 :仕様書無しさん:2011/03/08(火) 02:16:46.56
いつもの厨レッテル張りご苦労さまです。
理解力のなさを叩かれて躍起になっちゃったんだね。

682 :仕様書無しさん:2011/03/08(火) 19:21:12.38
すぐに話題が脱線するアホが何言ってんだか

683 :仕様書無しさん:2011/03/08(火) 20:56:00.79
脱線つかこのスレいつ本筋?やってたんだw

684 :仕様書無しさん:2011/03/09(水) 00:20:59.00
馬鹿に使わせることが前提なら、ライブラリやら部品やらはとにかく他がcatchしない例外
javaなら検査例外にもかからない非チェック例外のサブクラスに詰めて投げて、
馬鹿に触らせないベースクラスでまとめて処理して、
極力馬鹿に例外を触らせないようにするのが、一番安全だと思う

それでもぬるぽやparse失敗での例外を無視してはバグを作りこむのだけれど
//こういう狭い範囲においては、検査例外は便利だw

685 :仕様書無しさん:2011/03/09(水) 00:33:48.67
馬鹿の定義が、プログラムをめちゃくちゃにする人なので
どんな方法を使ったところで、めちゃくちゃにする。
つまり、馬鹿を想定するのは意味が無い。

はい、馬鹿が使うと言う前提は無視しましょーw


やっぱり、例外のほうがいいんじゃね?
ちゃんと使えば(当たり前のこと)
戻り値よりも便利でしょ。

686 :仕様書無しさん:2011/03/09(水) 00:52:07.78
>>684みたいなことは戻り値だけじゃ無理だしなー。
エラーのバケツリレーなんて、最後までバケツが運ばれてくるかも怪しいし、
そもそもバケツ変わったら全修正とかアホすぎることはやりたくはないわw

687 :仕様書無しさん:2011/03/09(水) 01:13:52.93
例外を使わせないGoogleはクソって話は、何スレ目くらいに出てる?

688 :仕様書無しさん:2011/03/09(水) 01:22:18.87
エラーをバケツリレーするっていう発想は、例外的な発想だな。

689 :仕様書無しさん:2011/03/09(水) 01:33:58.38
>>687
5スレぐらい前に終わってる話。
Googleは例外。作り直すなら例外を
使うとGoogleは言ってる。という結論。

690 :仕様書無しさん:2011/03/09(水) 06:52:11.51
>>689
でもそんな場面ないよねって暗にいってるように見えるな
あの書き方は

691 :仕様書無しさん:2011/03/09(水) 12:46:34.06
馬鹿を想定する意味がないって、このスレタイなのにかw

692 :仕様書無しさん:2011/03/09(水) 15:37:15.95
>>686
>エラーのバケツリレーなんて、最後までバケツが運ばれてくるかも怪しいし、

多相型推論を備えた関数型言語の場合、一般に値のバケツリレーは保証される。
これは直和型と呼ばれる厳格で階層的なデータ型定義が実現できていることによるもの。
(具体的には、Haskellなら newtype宣言、Standard MLならば datatype宣言と呼ばれる。)

たとえばStandard MLの場合、もしもバケツリレーの途中でコードに検査漏れがあれば、
コンパイル時にワーニングとして報告されるので、容易にミスを修正できる。
ワーニングを無視して実行させることは可能だけど、
その場合に漏れがあるケースを実行すると実行時エラーとなる。

>そもそもバケツ変わったら全修正とかアホすぎることはやりたくはないわw

Standard MLの場合、(クラスというOO概念は無いけど)抽象データ型をモジュール定義できるので、
バケツが変わった場合でもコード修正箇所を特定モジュールに限定させることも可能。

ただし、これらの厳格な型システムにも「抜け道」があって、その一つが例外。
(他の抜け道には、参照型による破壊的代入など。)
だから、規模の大きな開発になると、モジュール内部の関数間では便利な例外を使う事もあるけど、
モジュール間インターフェイスではいわゆる「バケツリレー」でエラーを渡すのが原則になる。

このスレ、手続き型言語限定ではないと思うので、参考まで。

693 :仕様書無しさん:2011/03/09(水) 19:51:25.71
ミソもクソも一緒くたにして議論する意味を無くしてしまうのが、例外厨のいつもの戦術。

694 :仕様書無しさん:2011/03/09(水) 23:58:02.88
言語によってはサポートがあるつっても、大抵の人にゃ縁のない言語だけどな

695 :仕様書無しさん:2011/03/10(木) 10:20:50.51
汎用性の無い言語独自の機能よりも
厳格なコーディングルールが必要だろう

696 :仕様書無しさん:2011/03/10(木) 13:23:31.16
今日はどこいこうかな

http://www.ikebukurobb.com/girls/

http://www.hatu-school.com/ladys.php

http://www.jk-style.tv/pc/girls/

http://www.westkawaguchi.com/main.html

697 :仕様書無しさん:2011/03/10(木) 19:59:57.51
ふざけんな男の娘はどこだよ!

698 :仕様書無しさん:2011/03/14(月) 20:52:32.52
 現在都内で起こっている輪番停電の情報や電車の運行情報なのどがwebでの情報の取得が難しい形になっています。

 そこでアンドロイドやiOSなのどのアプリでみんなで修正できるデータベース型のアプリを作成したい思ったのですが 

 すいません、自分は都内の工業大学に通っているものなんですがなにぶん頭が悪いもので発案しかできません

 どなたか一緒にデータベースがたアンドロイド携帯やiOS向けのアプリを作成してくれる学生の方いらっしゃいませんか?

 twitterだけだとどうにも運行情報がわかりにくいです。みんなで編集できるような簡単なデータベース型のアプリを作成するだけでも

 できないでしょうか?

       暇なを持て余している学生で構いません。協力してもらえませんか?  Mail: bbun■hotmail.co.jp    ■=@

699 :仕様書無しさん:2011/03/14(月) 21:18:35.66
>>698
ダメだ
何言ってるのかさっぱりわからない
Unityやろうぜってことでいいのか?

700 :仕様書無しさん:2011/03/14(月) 21:43:50.28
俺が不便だから作れ、俺の手柄にする

701 :仕様書無しさん:2011/03/14(月) 23:40:13.81
>>698
別に仕組みはそんなに難しくないが、問題はインフラと見せ方な。
どれだけの人数を見積もってんのか知らんが、
ある程度の負荷に耐えられるだけの鯖が当然いる。
んで、見せ方な。Wiki程度ならそこらに無料のあるんだし、それ使えばいい。
運行情報が見辛いなら、どういった見せ方が効果的か案はあるのか。
また、誰もが編集できるというなら、知識のないものでも簡単にできるようにしなければならん。どうする。
ここまで絵を書いたら、始めて技術屋に可能かどうか聞いた方がいい。
発案つーか、そういうのはせめて企画書の一枚も書いてから言え。

まぁはてなあたりで言えば、暇人が「Rubyで書いてみた」とかいるかもしれんが。

702 :仕様書無しさん:2011/03/14(月) 23:58:06.46
>>698
http://teideninfo.tepco.co.jp/flash/index-j.html
これで駄目なのか? 
スマートフォン用はないがhtml・Flashと携帯版があるが。
電車はないが。

703 :仕様書無しさん:2011/03/15(火) 00:01:16.72
>>701
2chで一番もっともな返信でした。
企画書の一枚・・・・・なるほど、すごくあたりまえなことに気づきませんでした・・・

すこし書いてみてほかのところで呼びかけてみます。
こんな未熟なレスに返信をくれてありがとうございます。

704 :仕様書無しさん:2011/03/16(水) 20:07:35.93
放射線量計測サイト radio.2ch.net を作ろう
http://dso.2ch.net/test/read.cgi/sakhalin/1300188770/

705 :仕様書無しさん:2011/03/16(水) 22:10:05.60
みんなでカキコならwikiでいいじゃんw

706 :仕様書無しさん:2011/03/18(金) 19:57:37.88
>>659
カスだな。
RuntimeErorrを自作すんなよ。
それからお前を、例外をデバッグ
ツールだと思ってるだろ。
例外はあくまでifと同じプログラムが
正常に動いてる事を前提とした制御機構だ。
javaと.netの様にデバッグ用に使えるのは少数派。
もともとコンストラクタとオペレーターの
オーバーロードで外部リソースなんかを確保できず戻り値を
返せない場合のために用意されたもんだ。
下らないことを吐くな。


707 :仕様書無しさん:2011/03/19(土) 01:50:57.26
>>706
頭固いぞ。

prinfは本来デバッグツールではないが、
デバッグに使うのと同じように
例外もデバッグに使える。
それだけの話だ。

708 :仕様書無しさん:2011/03/19(土) 09:30:25.78
使えなくはないけど、ブレーク置けば済む話だから普通は使わないわな
それ以外の手段を実行できない人の苦肉の策だろうから、バカだなぁって思うけど、否定はしないでおこう

709 :仕様書無しさん:2011/03/19(土) 09:43:05.69
>>708
いや、ブレーク使うには一旦コードを再実行しないといけないだろ?
例外は、デバックのために設置するのではなく、
普通の設計、普通のコーディングで普通に使う物。

そのなかで「ブレーク置きたい事態」になったとき
例外はすでに使われてるから、ブレーク置くまでもなく
状況が把握できる。

それに例外を使っておけば、例外をブレークの条件とすることもできる。
コードのあちこちにすでにブレークが仕込まれてると考えればいいよ。
そして例外をデバッグログに出力するようにしておけば・・・

そう考えると、コード中にバグを解析するためのコードが
たくさん埋めこまれていることになってるんだ。
想像してみ。コードのあちこちにバグ検出ポイントがある所を。

710 :仕様書無しさん:2011/03/19(土) 09:50:55.88
> いや、ブレーク使うには一旦コードを再実行しないといけないだろ?

コードを再実行しないといけないという意味は、
バグがあると想定してない箇所で問題が起きたとき、
そこにブレークポイントを予め仕掛けておくことは不可能だから
再度実行しないといけないという意味。

例外は想定外のことが起きたら、すべて捕まえるように
作るのが正しいやり方だから、正しく使っている限り
想定外の動作を記録できる。


711 :仕様書無しさん:2011/03/19(土) 11:33:25.06
>>709
言いたい事は理解した
理解したが、それはバグ発見に繋がるけれど、デバッグのために使うわけではないな

printfを引き合いに出してるので、そのために例外を突っ込んでブレークする意味だって読み取れる
目的と用途の違い
例外はあくまでも、想定している処理が完遂できなかったことを示す、戻り値の一種みたいなもの
デバッグにも使えるっていう表現は、やっぱ、ちょっと語弊あると思う

712 :仕様書無しさん:2011/03/19(土) 11:36:19.24
追記。706がバカだって思ってる部分に関しては否定してないからな

713 :仕様書無しさん:2011/03/19(土) 12:12:17.76
int value = getValue();
if (value == -1)
{
 value = 100;
}
else if (value == -2)
{
 log("エラー");
 return -1;
}
---
int value;
try
{
 value = getValue();
}
catch (NoValueException ex)
{
 value = 100;
}
catch (NoResourceException ex)
{
 log(ex);
 throw new SystemErrorException(ex);
}
---
コメントやマジックナンバーを使用しなくても、コードだけで仕様を表現しやすくなる
というのも、例外の利点ですね。

ただ、例外に慣れきれない人が、下のようなtry-catch句を見てしまうと、
強いストレス性の障害を起こして、胸が重苦しくなったり、
不眠症や拒食症・性機能障害などをを併発しちゃったりするものですから、時々使うのを躊躇してしまいます。

714 :仕様書無しさん:2011/03/19(土) 13:27:46.01
マジックナンバーって今日び新人でも使わないわ

715 :仕様書無しさん:2011/03/19(土) 13:59:22.68
>>709
きみの言うデバッグって何?
まさか単体テストでわかるnullポとかオーバーランの類いじゃないよね。
引数の間違いなら契約プログラミングで済む話だし...。
きっと演算結果がおかしかった時の事を言ってるんだよねっ、ねっ。

716 :仕様書無しさん:2011/03/19(土) 14:27:45.12
>>714
新人じゃなくても多用する奴はいるよ。
底辺マじゃなく、大手直属みたいなとこの社員の職業マあたりがヤバイ

717 :仕様書無しさん:2011/03/19(土) 14:37:25.30
例外はあらかじめ定義されていなければならないからね。

718 :仕様書無しさん:2011/03/19(土) 15:40:18.20
>>715
逆に、バグとはなに?と聞いてみたいんだが。

君がいつも「バグですね」といってるアレのことだよ。
デバッグとは、そのバグを治すことだよ。


719 :仕様書無しさん:2011/03/19(土) 15:51:27.16
俺「君、単体テストは終わったかね?」
君「はい、単体テストの結果動かなかった所が10箇所ありました」
俺「バグが10個か。それでデバッグはいつ終わる?」
君「いえ、デバッグはしません」
俺「?」

720 :仕様書無しさん:2011/03/19(土) 15:54:04.91
俺「君、単体テストは終わったかね?」
君「はい、単体テストの結果、NullPointerExcetionが発生する箇所がありました。」
俺「バグが発見したかよくやった! それでデバッグはいつ終わる?」
君「いえ、これはバグとは言いません。だからデバッグとも言いません」
俺「?」



721 :仕様書無しさん:2011/03/19(土) 16:00:26.46
直ちにプロジェクトに影響を及ぼす数値ではない

722 :仕様書無しさん:2011/03/19(土) 16:08:24.26
debugでバグ取り作業のことなんだけど、ちょっと意訳しすぎちゃった人はいると思う
デバッグというとトレースのことだって思ってる人とかもいる気はする

>>715
契約プログラミングを例えに出すのはあんまり現実的ではないよ
個人や小規模、もしくは逆にものすごく大規模とかならわかるんだけど
そもそもサポートしてくれる言語がマイナーで実用に向かない
全員が理解してるようなメンバー集めるのもちょっとアレだし、学習コストが無駄にかかる

723 :仕様書無しさん:2011/03/19(土) 17:48:08.83
100歩譲ってぬるぽなどは単体テストをする前の
開発段階ででないようにするべきだ。
と言いたいと解釈してあげたとしてもだ、

それをバグと呼ばないというだけで
例外だと
バグを見つけるのが簡単になる

開発のミスの把握が簡単になる。
と呼び名が変わるだけ。

724 :仕様書無しさん:2011/03/19(土) 19:19:53.00
他の会社はどういうか知らんけど、うちは
リリース後の動作不良をバグという。
開発行程のものをわざわざバグと言わない。
開発途中である以上、そこで確認できた
問題は、想定外の動作では無いからね。
全てのレビューとテストを掻い潜って初めてバグ扱いになる。


725 :仕様書無しさん:2011/03/19(土) 19:30:09.24
>>722
別に契約は、言語に依存しないよ。
OOがCでも出来ますよって話と同じ。
学習コストは掛かるだろうけどね。

726 :仕様書無しさん:2011/03/19(土) 20:21:20.65
>>723
開発ミスを把握し、簡単にミスの原因を
見つけるだけならthrowを使う必要
無いわけだけれども。
それはJava登場以前の言語がどうやってたか知ってれば解る筈。

727 :おじゃばさま:2011/03/19(土) 20:35:52.49
>>706
カスはお前だ。いや、カスに失礼だったな。
自作例外はあくまで例として書いただけであって、本当にそうするわけじゃねーよ。そのぐらい分かれ低能。
それとさ、お前は仕様外の引数が入ってきた場合どうするつもりだよ?
契約プログラムでも使ってるならともかく、そうでないなら実行時にチェックする以外にあるめぇ。
それとも何か? テストを十分にすれば、仕様外の引数が入る確率が0になるとか妄想抱いてるのか?

当たり前だが、よっぽどのことがない限り、仕様外の引数が入ってくる可能性はあるんだよ。
あまりに例外的なケースは除くとしてな。

そんな場合は例外以外に手段があるとでもいうのか?

728 :仕様書無しさん:2011/03/19(土) 21:17:53.46
あるだろ。

729 :仕様書無しさん:2011/03/19(土) 22:06:25.14
【システム障害】 みずほ銀行 高い信頼性を求められる銀行システムに何が起きたのか? 大規模障害を招いた「夜間バッチ処理」
http://ninja.2ch.net/test/read.cgi/newsplus/1300525602/

730 :仕様書無しさん:2011/03/19(土) 23:20:27.93
>>726
ミスを簡単に見つけるためにthrowを使うんじゃなくて
throwを使ってるから、ミスが簡単に見つかる。

順番が逆。

731 :仕様書無しさん:2011/03/20(日) 02:17:39.99
ブレークポイントとかログ出力とかは
デバッグのためにわざわざ作業を追加しないといけない。

例外は本来プログラムのエラー処理として
つくるものなので、そのついでにデバッグの
助けとなる情報が出力されるというのは
素晴らしいことだよ。

もちろん例外だけを使ってブレークポイントなどを
使うなって話ではなく両方を使う。

732 :仕様書無しさん:2011/03/20(日) 03:49:25.67
【結構迷う】C vs. C++【どっちで行こうか】
http://hibari.2ch.net/test/read.cgi/tech/1207419469/

733 :仕様書無しさん:2011/03/20(日) 08:52:40.33
throwの追加も作業ですよ

734 :仕様書無しさん:2011/03/20(日) 14:25:46.37
ライブラリなら、ライブラリ制作側が
作っているので、throwの追加は必要ないよ。

自分で作ったところであっても
エラー値で返す代わりに例外を返すだけだし、
そうすると、付属してエラーが起きたファイル名や行番号
それを呼び出すに至ったスタックトレースの表示が追加される。

エラーの値 < エラーの値+ファイル名+行番号+スタックトレース

735 :仕様書無しさん:2011/03/20(日) 14:28:14.97
-1という値を見て、これがエラーかどうかは
マニュアルを見ないとわからない。

しかし例外だと、それがエラーだとわかる。

これで出来ることがの一つがデバッガのエラー対応
例外が出たら停止するというブレークポイントの設定が行える。

736 :仕様書無しさん:2011/03/20(日) 14:52:39.60
C#だと行番号なんか出ないんだけど、なんの言語で例外に行番号が出るわけ?

737 :仕様書無しさん:2011/03/20(日) 15:14:40.76
は?普通に出てるが?
http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_018/csabc018_012.gif

738 :仕様書無しさん:2011/03/20(日) 15:34:28.92
つーか、出るわけねーだろ。そりゃ開発環境でやってるからだ。
インスコーラー作って、ソースのねー開発環境じゃねーところで例外出してみろ

739 :仕様書無しさん:2011/03/20(日) 15:36:18.55
はぁ。

740 :仕様書無しさん:2011/03/20(日) 15:41:48.38
>>738
ソースのないところで、行番号でてなんか意味あるわけ?

741 :仕様書無しさん:2011/03/20(日) 15:50:38.01
>>740
意味の話をしてるんじゃなくて、>>735で行番号が出るって言ってるから、でねーよって言っただけ。

742 :仕様書無しさん:2011/03/20(日) 15:52:42.29
>>741
だから行番号が出てる画像出しただろ。

そしたら、後出しでソースがない所では
ないといいだしたよな?

後出しすんな。最初からいえ。

ま、どうせ知らなかっただろうけどなw
違うか?

743 :仕様書無しさん:2011/03/20(日) 15:59:21.44
>>742
違うよ。
お前はあれか? 例外を使うときソースがある場合だけしか使わんのか。
ライブラリが例外ださねーとでもいうつもりか?
運用中に例外吐かねーとか言うつもりか?

デバッグ中にだけ役立つ情報見てどうするんだよ。
大体、ソースある環境だったら、例外情報見るより、ソース見てデバッガ回した方が確実だ

744 :仕様書無しさん:2011/03/20(日) 16:01:46.24
>>743
違うわけ無いだろw

例外を使っていれば行番号が出ること
ぐらい知っているはず
その上ででないと言えるわけ無いだろう。

お前はあれか? 例外を使うときソースがある場合で使わんのか。
つまりお前は開発をしたことがない。ってことになるが。


745 :仕様書無しさん:2011/03/20(日) 16:07:20.64
デバッガを正しく使えないプログラマ多いね。スレ立てたら?

746 :仕様書無しさん:2011/03/20(日) 16:09:53.49
> デバッグ中にだけ役立つ情報見てどうするんだよ。

バグ直すんじゃねーの?
そもそも、「デバッグ中だけで役に立つ情報」があるからこそ
デバッガ使うんだろうが。

どちらでも同じように情報がわかるなら、あえてデバッグする意味ないよなw


お前本当にプログラマか?

747 :仕様書無しさん:2011/03/20(日) 16:11:56.72
リリースビルでもちゃんと行番号でるけど?
http://d.hatena.ne.jp/siokoshou/20071105

さっさと謝っちゃえよw

748 :仕様書無しさん:2011/03/20(日) 16:21:53.66
>>744
だから、デバッグ時にのみ使える情報だったら、こっちの方がマシだろ。
http://www.dotup.org/uploda/www.dotup.org1445336.png


ついでに、>>747
リリースビルドだと出るが、インストーラーでソースのない環境だと当然でない。
http://www.dotup.org/uploda/www.dotup.org1445340.png

大体、ソースのない環境で行番号ってどうやるんだ? 意味不明なんだが……

使えない情報だわ。マジで

749 :仕様書無しさん:2011/03/20(日) 16:27:09.34
>>748
落ち着け、その画像は例外だぞw

スタックトレースよりも例外をブレークポイントで
止めたほうがより情報がわかるいう話ならわかるが、
そもそも例外が意味ないって話じゃなかったのか?w


いや、そもそもは例外に行番号がでないって話だっけ?w

ソースがない環境でも、行番号出るぞ。
リリースビルドを他のマシンに持って行って実行したから確かだ。

750 :仕様書無しさん:2011/03/20(日) 16:32:38.48
> 大体、ソースのない環境で行番号ってどうやるんだ? 意味不明なんだが……
>
> 使えない情報だわ。マジで

そりゃ、ソースコードがないところで行番号でても
意味ないだろw

意味の話をしてないというのなら、
使えないとか言うなよw

751 :仕様書無しさん:2011/03/20(日) 16:41:20.89
ソースのないところでは使えないだろとか、
ブレークポイントだってソースのないところじゃ使えないだろ・・・

もうね。各種デバッガ技術は
ソースも開発環境もないところでは使えないとか
早く言えばいいのに。

752 :仕様書無しさん:2011/03/20(日) 16:47:54.73
まあまあReleaseBuildでは行番号が出ないってことにしてあげようよ
でそれが例外が使えない理由にどう繋がるかがわからん

753 :仕様書無しさん:2011/03/20(日) 16:48:22.43
もうね。何かに役に立つことがあるというのに、
それ以外では役に立たないから
意味が無いという、そういう考え方は馬鹿だと思うわ。

754 :仕様書無しさん:2011/03/20(日) 17:04:48.96
ありがとう。
一連の議論で例外投げるよりassertでコア吐かせる方が有用だということがわかった。

755 :仕様書無しさん:2011/03/20(日) 17:14:58.17
と、涙がらに訴えるのであった。

※assertはリリースビルドでは
意味がありません

756 :仕様書無しさん:2011/03/20(日) 17:28:17.02
リリースビルドじゃないとリリースしちゃいけないと勘違いしてない?

757 :仕様書無しさん:2011/03/20(日) 17:28:53.33
あと、ちゃんとコンパイルオプションとか把握してる?

758 :仕様書無しさん:2011/03/20(日) 17:40:01.49
そもそもC#ってほぼ完璧に元に戻せるしな
Reflector使ってびっくりしたわ
定数は戻せないけどホントにそれだけだしな

759 :仕様書無しさん:2011/03/20(日) 18:35:07.89
前にもいたけどassertと例外の使い方の違いを知らない人がいるね。
例外の代わりにassetを使うとか、それはない。
使い方が違うんだから。

わかり易い例でいうと引数をともなう関数Aがあったとして、
その関数Aの中で引数のチェックをするときは例外を使う。

逆に関数Aを呼び出す前に関数Aの引数を
チェックしたいときはassertを使う。

760 :仕様書無しさん:2011/03/20(日) 19:19:57.02
深刻な電力不足の最中、パチンコ店だけが節電協力せず
http://www.youtube.com/watch?v=N_SpqfiBaMI&feature=


761 :仕様書無しさん:2011/03/20(日) 19:37:37.01
>>752
誰も例外が使えないとは言ってないんだが……

実際例外ってのは、製品出荷後も使うものだろ。
その時に、行番号なんて出力されないじゃないか。
それだから出ないと言っている。その際に役立つ例外情報ってのは、基本行番号抜きだろ。

基本、例外の中の行番号が出ないと言ってるんだよ。
例外自体は使えるわ。

お前らみたいなのが行番号が出るからとか言って、数千行のメソッド書いて役に立たんスタックトレースでも吐かせるんだろうよ。

762 :仕様書無しさん:2011/03/20(日) 19:44:17.47
>>761
お前も頭が悪いやつだなw

製品版で出ないからなんだって言うんだよ。
開発版で出るだろうが。

763 :仕様書無しさん:2011/03/20(日) 19:49:27.34
>>759
え?
そのassertの使い方になんか意味あるの?

764 :仕様書無しさん:2011/03/20(日) 19:52:02.07
>>763
経験不足だな。

長くやってれば経験があると勘違いしてるなら
大間違いだぞ。

この一年間でなにか新しいことができるようになったか?

765 :仕様書無しさん:2011/03/20(日) 19:53:03.88
>>764
ねぇおしえてよw


766 :仕様書無しさん:2011/03/20(日) 19:55:45.53
>>765
assertは実行時に無くなっても良い場所で使うんだよ。

それは関数の中でのみ必要とされるチェック。
つまり関数のロジックのチェックにのみ使うものだ。

assertは関数のインターフェース、引数のチェックには
使ってはいけないんだよ。実行時にどんな値が入るかわからないからな。

767 :仕様書無しさん:2011/03/20(日) 19:56:43.62
リリースビルドじゃないとリリースしちゃいけないと勘違いしてない?


768 :仕様書無しさん:2011/03/20(日) 19:57:01.86
えっ

769 :仕様書無しさん:2011/03/20(日) 20:00:43.96
>>767
リリースビルドでリリースしてはいけないと思ってないか?w

assertを使ったばかりに、リリースビルドでリリースできなくなるのは
愚の骨頂だ。だからそういう所にassetを使うなということになる。

分かったか?

770 :仕様書無しさん:2011/03/20(日) 20:36:40.29
>761
だから行番号が出なかったら何やねん
何が言いたいねん

しかも行番号が出なくても困らんと言ってる人間が
糞長いメソッドを書くというレッテル貼りに繋がる理由もわからん

お前主張が支離滅裂だぞ

771 :仕様書無しさん:2011/03/21(月) 01:08:59.49
>>759
こういうことけ?

public class Caller {
  public static void main(String[] args) {
    String a = "any value.";
    Callee callee = new Callee();
    assert a != null;
    callee.print(a);
  }
}

public class Callee {
  public print(String value) {
    if (value == null) {
      throw new NullPointerException();
    }
    System.out.println(value);
  }
}

わからんでもないが、引数チェックパラノイアかも。
漏れなら、publicメソッドの引数チェックはifを使うが、例外はあんまり使わん。falseとか-1(エラーを示す値)を返すほうが多いかも。
理由は、例外処理で
 try {
     myInstance.anyMethod(xxx);
 } catch (Exception e) {
   // 何もしない。なんで例外飛ぶのかわからないし、無視しても動くから問題はない。
}

とかを他のプログラマーにやられたらどうしようもないから。
コメントとかjavadoc/doxygenに書いた「userIdにnull・空文字入れたらエラー(falseを返す)」とかを参照してくれって方が間違いが少なくて済む。

772 :仕様書無しさん:2011/03/21(月) 01:45:41.31
>>771
> こういうことけ?

そういうこと。assertはリリースビルドで
消えるというところが鍵

リリースビルドとデバッグビルドで動作(関数の仕様)が
変わってはいけない。privateメソッドならまだ考える余地はあるが、
少なくともpublicメソッドなら、変な引数を与えたら例外を返すという
仕様なのだから、それがリリースビルドで変わるというのはありえない。


> 理由は、例外処理で
その理由はありえない。

> なんで例外飛ぶのかわからない?
falseや-1を返したところで、それと同じように「なんでエラーを戻すかわからない。
エラーを無視して無動くから問題はない。」となるだけだろう?
状況は全く同じだ。

コメントとかjavadoc/doxygenに書いた「userIdにnull・空文字入れたら例外を返す」とかを参照してくれって方が間違いが少なくて済む。
これも状況は全く同じだ。

773 :仕様書無しさん:2011/03/21(月) 02:05:21.26
例外を使ってない → 例外がない言語を使っている → C言語 → 開発効率が悪い → 規模が小さい → 一人で作っている。

これに当てはまってる状態の人には分かりにくい話なのかもしれないけど
(public)関数を作った時点で、この関数は他人が呼び出すもの。
他人を信用しないコードを書かなくてはならない。

でないと、この関数は○○を引数に与えると
不正な動作をする。というバグとして報告されることになる。


774 :仕様書無しさん:2011/03/21(月) 02:09:17.04
>>771
> 漏れなら、publicメソッドの引数チェックはifを使うが、例外はあんまり使わん。falseとか-1(エラーを示す値)を返すほうが多いかも。

これは意味が分からない。

ifを使うが例外を使わないとはどういう事だ?

普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない。

またfalseや-1を返す場合にしてもifを使うだろ?
お前の言う引数チェックパラノイアは、falseや-1を返したところで
同じように発生してるじゃないか。



775 :仕様書無しさん:2011/03/21(月) 02:10:22.85
>>772
「変な引数を与えたら例外を返すという仕様」
なんて誰が決めたのか知らんよ、俺は。
C++とかJavaとかC#とかRubyとかPythonとかPerlにそんな仕様はねえ。

……いや、仕様書ちゃんと読んでないだけかも知らんが、「引数に問題がある際は必ず例外をスローすること」と
記載された文章を俺は知らん。

申し訳ないが教えて欲しい。俺ヘタ打ったかもしれんからな。

776 :仕様書無しさん:2011/03/21(月) 02:15:26.76
>>775
お前の会社では、仕様書は誰が作るんだ?
言ってみろ

777 :仕様書無しさん:2011/03/21(月) 02:20:58.14
>>776
俺だが?

つまりおまいは「引数のエラーは必ず例外を出すこと」と決めて他人に強制してるわけな。
俺だったら「例外にしても例外にしなくてもいい。でも、どうしてそうしたのか理由は聞かせてね♪」位にする。

「必ず〜でなければならない」なんてことはないんでな。

778 :仕様書無しさん:2011/03/21(月) 02:24:16.32
>>777
お前は話の流れを理解していない。
見当違いのレスをしてるよ。

assertはコンパイル時に消えるのだから
(お前が作った)仕様がデバッグビルドと
リリースビルドで動作が変わるような使い方を
してはいけないという話だろ。

そして、引数のチェックは例外。
assertは自分が作ったコードの動作確認のために
使うものだ。とそういう話だ。

779 :仕様書無しさん:2011/03/21(月) 02:26:31.71
あと、「必ず」なんて
ひとことも言ってないわ。

自分の脳内で作り上げた話に
自分で文句付けるな

780 :仕様書無しさん:2011/03/21(月) 02:30:47.56
>>779
言ってないが

「普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない」

って書いてるだろ。
つまりお前は引数のエラーには例外飛ばすのが常識なんだわ。
そうでなければおかしいと思っている。
んだからわざわざ「必ず」なんて書いてさしあげましたわ♪ って感じ。

つか突っかかってきたのはお前だぜ?

781 :仕様書無しさん:2011/03/21(月) 02:32:24.25
>>780
だからいい加減、assertの話に戻れや。
見当違いのレスするな。

突っかかってきたのはお前だっていうの。

782 :780:2011/03/21(月) 02:32:29.23
……あー、不毛だな。

783 :仕様書無しさん:2011/03/21(月) 02:33:14.94
いやならこなくていいんだぞw
さっさと消えてもたったほうが
俺の思うつぼだ。

784 :780:2011/03/21(月) 02:34:28.62
>>781
つーかね、何が不快なのさ?

何にイラっとしてるのか意味がわかんねえんだよ、俺には。

785 :仕様書無しさん:2011/03/21(月) 02:34:48.14
例外機能がある言語の標準ライブラリで
エラーに例外を使わない言語なんてないよ。

引数のエラーに例外を使うのは
業界の常識。

786 :仕様書無しさん:2011/03/21(月) 02:35:49.86
>>784
お前、自分が見当違いのはないしてるのわかってないの?
話し戻すぞ。

>>771
> こういうことけ?

そういうこと。assertはリリースビルドで
消えるというところが鍵

リリースビルドとデバッグビルドで動作(関数の仕様)が
変わってはいけない。privateメソッドならまだ考える余地はあるが、
少なくともpublicメソッドなら、変な引数を与えたら例外を返すという
仕様なのだから、それがリリースビルドで変わるというのはありえない。


> 理由は、例外処理で
その理由はありえない。

> なんで例外飛ぶのかわからない?
falseや-1を返したところで、それと同じように「なんでエラーを戻すかわからない。
エラーを無視して無動くから問題はない。」となるだけだろう?
状況は全く同じだ。

コメントとかjavadoc/doxygenに書いた「userIdにnull・空文字入れたら例外を返す」とかを参照してくれって方が間違いが少なくて済む。
これも状況は全く同じだ。



787 :780:2011/03/21(月) 02:36:59.54
あーつまり

引数チェックでアレなら絶対例外飛ばすべきだ

って言いたいのか?

788 :仕様書無しさん:2011/03/21(月) 02:37:32.09
>>787
なんでassertの話をしないの?

789 :仕様書無しさん:2011/03/21(月) 02:38:55.33
>>787
少なくとも、標準ライブラリは
例外を返しているが?

790 :780:2011/03/21(月) 02:39:29.38
>>788
お前の話が抽象的過ぎてぜんぜん意味不明だから。

791 :780:2011/03/21(月) 02:40:59.81
>>789
どの言語のどのクラスのどのメソッド? 全部書いてみ。
標準ライブラリなんてあいまいなことを書かず、全部が全部そうだと証明してみれ。

792 :仕様書無しさん:2011/03/21(月) 02:41:39.47
>>790
あ、assertの話をしているのに
それを無視して関係ない話したの認めるんだw

お前が理解できてないだけじゃね?w

793 :仕様書無しさん:2011/03/21(月) 02:43:17.94
>>791
例外のある言語の標準ライブラリはそうだよ。

C++、Java、JavaScript、C#、Ruby、Python

794 :780:2011/03/21(月) 02:44:46.41
いや、お前が何言いたいのかさっぱりわからないからもっと具体的に言えっってこと。

795 :仕様書無しさん:2011/03/21(月) 02:45:14.34
>>794
お前が理解できてないだけじゃねw

796 :仕様書無しさん:2011/03/21(月) 02:46:06.74
assertをどういうときに使うかは
常識なんで、わからないなら
ぐぐればいいじゃないですか?

ググりましたか?

797 :780:2011/03/21(月) 02:48:05.86
「引数に変な値を突っ込んだ際、必ず例外を返す言語処理系を書け」
と言ってるんだよ。

798 :仕様書無しさん:2011/03/21(月) 02:49:21.13
ほら、「assert 例外 違い」でググッてきてやったぜ
勉強してから出直しな。

http://nokamoto.web.fc2.com/programming/assert_vs_exception.html
http://i-learn-try-error-and-try.blogspot.com/2009/04/assertexception.html

799 :仕様書無しさん:2011/03/21(月) 02:51:15.43
>>797
言葉は正しく使おうな。

処理系はライブラリとは違う。
例外を返すのはライブラリであって
処理系ではない。

こういうことで、お前の実力が分かってしまうんだぜw

800 :780:2011/03/21(月) 02:53:33.93
もちろんその言語系の標準クラスの全メソッド書いてもらうけどな。
そこまでしてもらわないと信じられないね。

>>796
というか、正直全部例外返すとか正気け? って思ったんだよ。

例えばRubyの String#to_i とか、「整数とみなせない文字があればそこまでを変換対象とします」ってあるだろ。
http://www.ruby-lang.org/ja/man/html/String.html#to_i
お前の話なら例外をスローしないとおかしい。

つか「public関数で引数がアレなら絶対例外飛ばすべきで戻り値でエラー伝達してはいけない」
なんていう話の方がおかしいんじゃね? という話なんだが。

おまいの中では例外でなければならないのはわかった。

assertをprivateメソッドで使っちゃダメなんですねーハイハイカワイソス状態。

801 :仕様書無しさん:2011/03/21(月) 02:53:52.55
あと、どうも俺が「標準ライブラリは例外を返している」の
”標準”の部分を無視してきそうだから、
ここらで釘を挿しとくかw

802 :仕様書無しさん:2011/03/21(月) 02:55:19.90
> もちろんその言語系の標準クラスの全メソッド書いてもらうけどな。

ググれよw
コピペする面倒を俺がやることで
ネット上で見れるマニュアをみること以上の
意味がなんかあるのか?


803 :780:2011/03/21(月) 02:55:26.31
いや「標準ライブラリ」って書いたろ、お前。
処理系はライブラリとは違うとか言って、お前は標準ライブラリって書いたんだから >>793

804 :780:2011/03/21(月) 02:56:20.06
>>802
お前はお前が正しいって認められたいんだろ?
俺に「すみませんでした僕が間違ってました」って言わせたいんだろ?

じゃあそのくらいの労力惜しむなよ。

805 :仕様書無しさん:2011/03/21(月) 02:58:03.84
>>800
> 例えばRubyの String#to_i とか、「整数とみなせない文字があればそこまでを変換対象とします」ってあるだろ。
それ例外の代わりにエラーを返してるわけじゃないじゃんw
それはエラーを返さないという仕様なだけ。

俺が言ってるのは「エラー状態を値で返すのではなく例外で返す」って話だぞ。
そもそもエラーにならない場合の話なんかしてないわw


806 :仕様書無しさん:2011/03/21(月) 02:58:51.14
>>804
> 俺に「すみませんでした僕が間違ってました」って言わせたいんだろ?

いいえ、このまま黙って帰ってくださいw
レスしないでくださいw



807 :780:2011/03/21(月) 03:05:09.93
……あーなんか久々にマジイラっとした。

たぶん漏れがイラっとしたのは「そうすべきだ!」みたいなのを見たときだと思うけどな。
戻り値で返したほうがいいかって判断のときもある。
十把ひとからげで機械的に例外とか言われるとマジムカつくんだよ。

「assert」とは「前提条件の宣言」であって、俺はこういう前提を考えてるっていうメモ書きでしかない。
例えばprivateメソッドの中身は俺に責任と支配権がある。
private関数の引数でミスってたら俺の責任だし俺が直すべきもの。だからassertでいい。
また、処理の途中で「必ず変数はこうなっているはず」ってのをメモ書きする程度でassertを使うことはある。

publicメソッドで全部例外飛ばすのが仕様なら、別インスタンスのメソッドは全部try-catchしなきゃいかんわけ。

 AnyClass a = new AnyClass();
 try {
    a.anyFunc();
 } catch (AnyException e) {
    // なんかしてくれ。俺は知らん。
 }

ってのを全インスタンスの全メソッドでやるべきだってことだ。
そこまでしたいならそうしてくれ。俺はよー面倒見きれんよ。

808 :仕様書無しさん:2011/03/21(月) 03:08:12.07
> publicメソッドで全部例外飛ばすのが仕様なら、別インスタンスのメソッドは全部try-catchしなきゃいかんわけ。

え? 全部って言った? ねぇ全部って言った?
全部する必要はないけど?w

戻り値でエラーを返したら、エラーチェックしないといけないよ。
それと何が違うのかね?
あ、全部とは言わないけどwww



809 :780:2011/03/21(月) 03:15:13.34
>>808
www が増えてるな。大分キレてんだろ? わかるよ。
かわいそうだな。まあ頑張れ。

>>774みれ。

「普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない。」

お前は「例外を使わないということの意味がわからない」と書いた。
お前には例外を使わない奴の意味がわからない。お前は例外を使うべきだって思っているわけだ。

まあ頑張れ。

810 :仕様書無しさん:2011/03/21(月) 03:15:59.88
例外は戻り値でエラーを返す方法の欠点を
解決するために作られたものなんだから
戻り値でエラーを返すよりも例外で返すべきなんだよ。

もし、それでも戻り値でエラーを返したくなったら良く考えてみ、
その返そうとしているのは、エラーではなくただの状態フラグだろ。

811 :仕様書無しさん:2011/03/21(月) 03:16:30.99
> ……あーなんか久々にマジイラっとした。

大分キレてんだろ? わかるよ。


812 :仕様書無しさん:2011/03/21(月) 03:18:24.87
>>809
日本語(ry

×例外を使わない
○ifを使って例外を使わない

なんでこう、自分の思い込みで
文章作って、それに文句つけるのかねぇ

813 :780:2011/03/21(月) 03:19:34.51
戻り値でも例外でもエラーを無視させたくないって意味では一緒だ。

例外に悪慣れする奴が居る。
ドキュメント見ようとせず、「何かトラブってる?」とたずねても「いえ問題ないです」っつって
とりあえず try - catchで凌いでた奴はいやってほどいたのさ。

んーなら戻り値と例外を織り交ぜて「あのー、この辺意味わかんなくって」って言わせるほうが
マシだってこと。
聞かれれば「あーここね、OK説明しちゃる」と話も出来るから。

814 :780:2011/03/21(月) 03:21:21.31
>>811
お互いキレてるんじゃね?

俺がイラっとしたのは「どうもこいつ例外万能主義じゃね?」って思ったことだよ。
「とりあえず例外」みたいな、なんも考えてないような表現のようには見えたんだよ。

そうでないなら俺の誤読だがな。

815 :780:2011/03/21(月) 03:37:25.13
残念だけどな、ン十名とかン百名とかのプロジェクトに参加すると例外万能とか戻り値でOKとか
そんな原理原則は通用しねーんだわ。

アホの子から天才サマまで居る。
アホの子基準でやらんと破綻する。天才は勝手に何とかするからな。
っつってもアホの子っつってもよくよく話し聞けば「あー、なんだ、参照渡しの意味わかんねーだけか」
みたいな話になるが、うまいこと他人から話引き出せるような書き方せにゃならんのだわ。

assertは俺が管理している内部の処理だけで使う。
例外飛ばすか戻り値でやるかは、問題の重大性による。
DBとか別サーバの接続問題とか、環境の問題であれば例外を飛ばす。
コーディングレベルの問題なら戻り値で処理するのが基本だが、ちょっと悩ましいところなら例外かも。
んで誰か眉ひそめてたら「キター!!!!!」っつってそいつに話しかける。ンで仕舞いだ。

そのくらいだわ、俺は。

別に全部例外にしたっていいが、俺は関わりたくねえな。

816 :仕様書無しさん:2011/03/21(月) 04:16:14.73
無知宣言してる馬鹿いつまでも相手するなよ
最初の方のレスで相手する価値がないことくらい明白じゃないの

817 :仕様書無しさん:2011/03/21(月) 04:54:26.08
で、行番号が出る出ないはなんだったんだ?
あまりに間抜けなことを言ってることに気付いて引っ込めたのか

818 :仕様書無しさん:2011/03/21(月) 07:14:28.89
>>810
例外は戻り値の代替手段ではないので
その結論は強引過ぎる

状態フラグ、実行時エラー、異常系
そのとき最善の方法で処理すれば良し。

819 :仕様書無しさん:2011/03/21(月) 10:42:28.70
エラーの返し方はいくらでもあるが、
そのメソッド名が表現する処理が完遂できないのは、想定外であり例外だ。
公開するメソッドならもちろんだし、非公開でも、なるべくお作法に従って例外投げれ。

どうしても例外を投げたくなけりゃ、返す値がエラーではない値になるように、
メソッドを相応しい名前へと変更して、戻り値の型をエラーを内包する相応しい物にしろ。
そこまでの事が出来ないなら、例外的なメソッドなんて作らず、お作法通り例外投げれ。

もちろん、いろんなエラー値が帰ってくるような糞関数でも、使うときはさして問題にはならんよ。
検査例外があるJavaはさておき、それ以外の言語の場合は、例外だってドキュメント見なわからん。
その点は戻り値エラーだって同じだ。まぁ例外は型があるから、メソッド名から推測できる場合もあるが。
どちらにせよ、その関数を使おうとしたときは、相応に調べるから問題になることはそうない。
例外自体は絶対に切り離せない仕組みだから、所々に戻り値エラーが混ざる形になって、
コーディングのスタイルは不統一になるが、その程度。大きな問題じゃない。

ぶっちゃけ、んな事は問題じゃない。戻り値エラーの一番糞な所は、改修の時。
例外ならメソッドの想定外だったすぐ判断できるし、回復や中断が明確になる。
だが、戻り値の場合、戻ってきた値の意味を毎回調べるハメになるんだわ。
改修のことまで考えたら、やっぱ戻り値でいろんな意味のある値を返すのは、相応しい選択じゃねぇよ。
業務的な意味の例外なら、いくつも型作るのもアレだから理解できるが、
それ以外でも戻り値エラーにするのは、本気でやめて欲しいわ。

820 :仕様書無しさん:2011/03/21(月) 11:09:38.05
まぁ、業務的な例外の場合、仕様の届く範疇だし、処理済みであるべきなので、
共通的な大元の処理以外で、catch しないといけないような例外として投げるべきではないけどな。

>>817
>>736が前提条件が抜けてる、単にアホな発言だったってだけっしょ。
後の発言見てたら言いたかったことは予想できるし、続ける意味がないっしょ。

>>818
戻り値でエラーを返すために、無理やり値を拡張することを回避する手段だわ。
810はそう言ってるんじゃ。解釈間違えてると思う。

821 :仕様書無しさん:2011/03/21(月) 13:04:25.29
例外は戻り値の代替手段ではなく、
戻り値でエラー値を返すことの代替手段だよ。

戻り値と、エラー値は全くの別物。
例外がない言語では、戻り値の中に特殊なルールを作って
エラー値を混ぜて返す。受け取り側でそれを判断して
戻り値とエラー値で振り分けて処理する。

そういうバッドノウハウを必要なくしたのが例外。

例外をなぜ特殊なものと考えるかな?
どういうときに使うかは、標準ライブラリでも参考にしろよ。

誰も、戻り値をやめて、全部例外にしろとなんて言ってないからな。
戻り値にエラー値を混ぜるのをやめて、それを例外にしろと言ってる。

822 :仕様書無しさん:2011/03/21(月) 13:23:51.40
戻り値でエラーを返す方法の一番の欠点は
全メソッドでエラーチェックをしないといけないことだ。

AnyClass a = new AnyClass();
a.anyFunc();
(次の命令)

もし、このanyFuncが戻り値でエラー値を返していたら
これではエラーが起きても正常に処理を続行(次の命令を実行)してしまう。

つまり、全部の関数で
AnyClass a = new AnyClass();
if(a.anyFunc() == エラー値) {
  //何かする。
}

このような面倒をみないといけない。手間がかかるってのもあるし、
エラー値が関数ごとにバラバラなので、これはエラーの場合なのか?
それとも単に戻り値をチェックしているだけなのか?ってわからない。

こんな欠点があるのに、そこまでしたいならそうしてくれ。俺はよー面倒見きれんよ。



823 :仕様書無しさん:2011/03/21(月) 13:26:24.15
×全メソッドでエラーチェックをしないといけないことだ。
○全メソッドでエラーチェックコードを書かないといけないことだ。

訂正しよう。例外だとエラーチェックをしなくてもいい、それは手抜きだ。と
捉えかねないからなw


例外は、「標準のエラーチェックコード」というのが存在している。
例外を使っていれば、何も書かない=デフォルトのエラーチェック処理。なんだ。
だからエラーチェックをしない。ということがありえない。


824 :仕様書無しさん:2011/03/21(月) 13:28:57.90
設計が下手くそなだけじゃねえか

825 :仕様書無しさん:2011/03/21(月) 13:31:43.37
はい、824がどこが下手か指摘して、上手な設計を教えてくれるそーです(爆笑)



826 :仕様書無しさん:2011/03/21(月) 14:08:46.40
>>824
答えられんのなら、でてくるんじゃねーよw

827 :仕様書無しさん:2011/03/21(月) 14:56:32.76
>>822
どうせほとんどの戻り値チェックしないといけないんだから
エラーが増えるのくらいどうってことないだろ。

828 :仕様書無しさん:2011/03/21(月) 15:19:39.79
そこでまた、そもそも例外で処理すべきエラーって何よ?に戻る。
EOFはエラーじゃないだろ?とか
FileNotFoundはどーなのとか。ループループw

829 :仕様書無しさん:2011/03/21(月) 18:39:30.55
>>828
だからそれは正常系と異常系に違いだろ。ループループ

830 :仕様書無しさん:2011/03/21(月) 20:46:29.85
>>827
ほとんどの戻り値(エラー)チェックは
やることは一緒なんだから
まとめたほうがいい。

例外だとまとめることが簡単にできる。

831 :仕様書無しさん:2011/03/21(月) 20:57:57.05
>>828
> そこでまた、そもそも例外で処理すべきエラーって何よ?に戻る。

君は「何を例外で処理すべきか?」と悩んでいるね。
なぜ君が悩んでいるか、その理由を教えてあげようか?

それはね、君のレスにヒントがある。
EOFはエラーか? FileNotFoundはエラーか?
君は例外だけを考えているから理解出来ないんだよ。

君に聞きたいのは例外ではなく関数の仕様の方だ。関数名でもいい。
もしGetConfigDataという関数で、Configデータを返すという仕様の関数であれば、
ファイルが見つからなければFileNotFound。
FileExistsというファイルチェック関数ならtrue/false(※重要 これはエラー値ではない)

よって例外がある言語で、関数の戻り値にエラー値を返すことはない。


(ファイルが見つからない場合にデフォルト値を戻す仕様だってありえるだろ厨へ。
エラー値を戻すか、例外を戻すか の話なのでデフォルト値を戻すというのは、
仕様が違うってだけで、的外れな答えです)

832 :仕様書無しさん:2011/03/21(月) 20:59:25.46
やることいっしょなばあいだけね。

833 :仕様書無しさん:2011/03/21(月) 21:00:20.68
>>832
エラーを受け取った後にやることはほとんど同じ。

834 :仕様書無しさん:2011/03/21(月) 21:01:00.10
なんでコンフィグかえすかんすうでファイルのっとファウンドなんか出てくるのかなー

835 :仕様書無しさん:2011/03/21(月) 21:01:30.84
>>833
やること一緒なばあいだけだね

836 :仕様書無しさん:2011/03/21(月) 21:08:36.87
>>834
configデータをファイルに保存している場合を想定してだよ。
ってか、これぐらい普通言われなくてもわかるだろw

837 :仕様書無しさん:2011/03/21(月) 21:09:13.75
>>836
わからないよおればかだから

838 :仕様書無しさん:2011/03/21(月) 21:10:52.69
>>837
なんとなく分かるw

839 :仕様書無しさん:2011/03/21(月) 21:13:24.07
>>836
そんなのしらねーよ。

840 :仕様書無しさん:2011/03/21(月) 21:14:54.42
じゃあ、どこにconfigデータがあると思ってたんだろうか・・・。

いいよ答えなくてw

841 :仕様書無しさん:2011/03/21(月) 21:22:44.91
知る必要があるのか?

842 :仕様書無しさん:2011/03/21(月) 21:32:13.39
知る必要ではなく、君がどこにconfigデータが保存されると思ったかだよ。

843 :仕様書無しさん:2011/03/21(月) 21:35:44.76
そんなのプログラムに関係ないんじゃないのかな

844 :仕様書無しさん:2011/03/21(月) 21:38:58.42
そりゃ、君が、configデータをファイルに保存するということを
思いつかなかったのは、なぜか?って話だからねw

845 :仕様書無しさん:2011/03/21(月) 21:57:50.47
ハードコーディングやプロセス間通信によって得られる場合もあるから、
「ファイル」に限定することはできないな。

846 :仕様書無しさん:2011/03/21(月) 22:02:39.46
馬鹿に構う馬鹿も全部まとめて吹き飛んでしまえ。
書き込むボタンを押す前に、レス返すほど価値のある内容か10秒でいいから考え直せよ馬鹿。
相手を黙らせるまで連投して、最後に書き込んだほうが勝ち、じゃねーんだから半島人みたいなことばっかすんなよ。

847 :仕様書無しさん:2011/03/21(月) 22:05:44.05
普通はファイルに保存するだろ。
ほとんど無いような例引っ張り出して話混ぜ返すなよ。

848 :仕様書無しさん:2011/03/21(月) 22:09:00.96
>>846
正直すまんかった

849 :仕様書無しさん:2011/03/21(月) 23:45:52.56
>>846
暇つぶしなんじゃね?

850 :仕様書無しさん:2011/03/21(月) 23:56:31.50
>>849
うんそうだよ
例外理解出来ない馬鹿を教育するのも
また暇つぶしではあるがw

851 :仕様書無しさん:2011/03/22(火) 00:02:34.46
暇つぶしなら他所でやれよ、馬鹿同士の乳繰り合いは寒いぞ

852 :仕様書無しさん:2011/03/22(火) 22:51:55.64
154 名前:名無しさん@お腹いっぱい。(東日本)[sage] 投稿日:2011/03/22(火) 21:35:11.33 ID:TWYMWmhX0 [3/3]
幾つの家が壊れたであろう。
幾つの家が流されたのであろう。
そして、幾つもの尊い命が失われた。これが現実。

亡くなった方々のためにも、生きなければならない。
一件の家を建てるのに3,000万。
4万件の家を建てるのには1.2兆円。
国民一人、10,000円あれば達成できる。
いや、1,000円でも100円でもいい。
復興のために少しだけ、力をください!


853 :仕様書無しさん:2011/03/22(火) 23:07:22.74
>>852
暇つぶしなら他所でやれよ

854 :仕様書無しさん:2011/03/23(水) 03:17:09.31
んなコピペしてる暇があったら節電するほうが有意義だと思うの

855 :仕様書無しさん:2011/03/23(水) 03:28:25.70
九州だから節電しても意味ないよw

856 :仕様書無しさん:2011/03/23(水) 09:24:23.57
んじゃカネ送ってやれよ屑

857 :仕様書無しさん:2011/03/23(水) 17:33:55.75
みずほが落ちたのは間違った例外処理のせいに違いない
戻り値にしておけば、一部顧客のデータが消えただけで済んだだろうに

858 :仕様書無しさん:2011/03/23(水) 18:03:35.02
はぁ?
頭大丈夫?

859 :仕様書無しさん:2011/03/24(木) 19:24:49.03
海外サーバーを経由してネットする方法を詳細に記している「書籍」知りませんか?
別に悪いことするために聞いているのではありませんがw
wikileaksのハッカーが、それをしていると聞いて興味を持ちまして


860 :仕様書無しさん:2011/03/24(木) 19:47:43.24
ただのてきとープロクシのことならどこにでもあるが。

861 :仕様書無しさん:2011/03/25(金) 01:22:01.66
とーあとかかもしらんけどここできくことではないわなあ

862 :仕様書無しさん:2011/03/27(日) 17:06:02.52
http://mikosuma.com/
あの事件、実は在日の仕業

863 :仕様書無しさん:2011/03/27(日) 23:30:49.93
Code Complete読めば?

864 :仕様書無しさん:2011/04/05(火) 17:31:45.55
tp://blog.livedoor.jp/sharepoint/archives/50102988.html

catch
{
throw;
}

これって何? メリット有るん? あるんなら、おせーーて

865 :仕様書無しさん:2011/04/07(木) 06:09:19.04
ない
tryを書いたらcatchしないとだめっておもってる人がたまにやってる

866 :仕様書無しさん:2011/04/16(土) 00:08:01.78
サイエンスZERO「人工知能がクイズ王に挑戦!(前編)

867 :仕様書無しさん:2011/04/22(金) 11:26:29.18
とらいきゃっちもでりげーともわかりません。


シンプルにアセンブラ展開できたら多少は理解できそうなんたがコンパイラが吐き出したカオスコード追いかけるのは大変だし…


868 :仕様書無しさん:2011/04/28(木) 11:10:09.17
http://hibari.2ch.net/test/read.cgi/tech/1302588918/546-579
> 561 返信:デフォルトの名無しさん[sage] 投稿日:2011/04/28(木) 03:25:09.83
> 次に、>>546のような深いネストがどうしても必要な場合
> 仮に例外で処理するなら error_handler() で catch するだろう
> そうすると途中の関数は例外処理がいらないから(デストラクタで処理できるリソースだけ使ってる場合は)簡単になるけど
> error_handler() を読むのが凄く難しくなる
> 深いネストを潜って source_of_error() まで到達する必要があるからね

869 :仕様書無しさん:2011/04/29(金) 11:48:47.98
どれくらいの粒度でエラー補足したらいいのかいつも迷う

870 :仕様書無しさん:2011/04/29(金) 16:11:51.40
必要なときでいいじゃない?

エラー送信の方では悩むけど
エラー補足で悩む必要あるのか?

871 :仕様書無しさん:2011/04/29(金) 20:01:23.60
うちは7行に一つくらいはエラーログ出るようになっとるわ。
ほかにも関数ごとに一回くらいとか、スタックトレース的に出るようなマクロ作ってるとか
いろいろやりようがあるわな。その辺は好みでいいだろう。
ただ、長年商売してると顧客サイドで落ちた時にログ収集してもさっぱりわかりません
はつらいからやっぱ多目に越したことはないと思うわ。

872 :仕様書無しさん:2011/04/29(金) 21:00:55.70
望んだ動作ができなかったら投げる
これが一番簡単

873 :仕様書無しさん:2011/05/03(火) 04:03:47.66
サラリーマン的に仕事けるのは大変だし…

874 :仕様書無しさん:2011/05/05(木) 19:22:42.85
例えがさっぱり意味不明w

875 :仕様書無しさん:2011/05/08(日) 12:15:25.80
>>862


876 :仕様書無しさん:2011/05/08(日) 12:50:27.21
>>864
デバッグのときにブレークポイントが貼りやすい的なもんじゃね?

877 :仕様書無しさん:2011/05/08(日) 12:58:56.73
そういや、ブレークポイントって未だに行単位だよな。

return foo();

ってかいて、fooが終了したときにブレークポイント貼りたいんだが。

878 :仕様書無しさん:2011/05/08(日) 13:12:47.92
>>877
return
  foo();

879 :仕様書無しさん:2011/05/08(日) 14:08:11.68
終了したときの状態でとめたい、でもローカル変数使いたく無い、って場合は
foo()のなかの末尾にしかけてステップアウトするか、
開始前でとめてステップオーバーで飛ばすかくらいしかないんじゃねーの
でも見たいのは戻り値だから、結局ローカル変数ないと確認できない気はするけれど

>>878
returnの前にfoo()が評価されっから、877に仕掛けても878と変わらんのじゃね

880 :仕様書無しさん:2011/05/08(日) 14:09:21.13
eax 見ればいいんじゃねーの?

881 :仕様書無しさん:2011/05/08(日) 14:17:17.81
foo()が戻した値をそのまま戻すんだから、その関数の戻り値を確認すればいいんじゃないの?

882 :仕様書無しさん:2011/05/08(日) 14:35:48.72
cとかはブレークポイント張りにくいから
関数の引数に関数を入れるような
入れ子にせず、一行づつ書く、
戻り値はいちいち変数に入れる
というマナーがあるよね。
最近は古い慣習という扱いなのかな。


883 :仕様書無しさん:2011/05/08(日) 14:41:27.31
そうすべきかどうかはその関数の性質によると思うな。

入出力も副作用もない数学の関数のようなものなら、必要がなければいちいち
変数に入れたりはしないと思う。

884 :仕様書無しさん:2011/05/08(日) 15:04:10.39
たしかに、画面に描画する関数を引数には
しないですね。妥当だとおもいます。

上記のマナーは、一切の入れ子禁止と
言うものでした。

885 :仕様書無しさん:2011/05/08(日) 18:11:33.20
foo(bar())
こんなコード書いていて、bar()が終了したときの値を見たい。

886 :仕様書無しさん:2011/05/08(日) 18:25:36.92
アセンブラレベルでデバッグしろよ。

887 :仕様書無しさん:2011/05/08(日) 18:27:40.59
>>885
とりあえずその行で止めてステップ実行進めてりゃどっかで見えるだろ。
最終的に foo() にステップインしたところでは見えるだろうし、
環境によってはそれより前でも見えるかもな。

888 :仕様書無しさん:2011/05/08(日) 22:49:05.29
ブレークポイントをbarの先頭にかけて、
(barを)抜けるところまでスキップ。

889 :仕様書無しさん:2011/05/09(月) 01:54:01.53
需要も0ではなく、そういう用途に使いたいときもあって
機能として実現も無理ではないはずだが、わかりやすい形での実装はみたことないな

大抵はコードのほうを無理くり対応させる形で目的を達成してる感

890 :仕様書無しさん:2011/05/11(水) 19:38:11.31
 あんまり関係ないんだが、DBのRollbackって明示的にする必要あんの?
Beginでトランザクション開始後、切断ないしクライアントの応答が途絶えたら自動でRollback。
Beginのあともう一回Beginを行うと、その間のトランザクションは、Rollbackまたはスタックされる。
スタックされた場合でも、Beginとcommitの数が一致しなければその間のトランザクションは全てRollbackされる。
接続を細かく切ってるようなら、わざわざ例外ブロックにRollback書く必要もないよな。
状況の情報を加えた例外は出す必要はあるけど。

891 :仕様書無しさん:2011/05/11(水) 20:36:18.94
今時はコネプーだから、接続を細かく切るってのが想像できん。

892 :仕様書無しさん:2011/05/11(水) 20:54:37.85
Javaのこねぷ〜でも切断する訳じゃないけど、getConnection()するしclose();すんじゃん。

893 :仕様書無しさん:2011/05/12(木) 01:40:59.43
>>890
ウェブアプリしか考えてねーだろ?

GUIアプリでエラーが発生したとき、
いちいちアプリが落ちてたらたまったもんじゃないよ。


894 :仕様書無しさん:2011/05/12(木) 20:59:32.81
GUI環境だからって接続しっぱなしにしてんの?
連続でやりとりすんならまだしも、
クライアント操作が無い間中DBサーバーのリソース食うのに。

895 :仕様書無しさん:2011/05/14(土) 00:07:19.56
そういうバカなのもあるよ。去年だか一昨年だかに関わったわ
そういう仕様がご所望だったらしくて、苦笑いしながらやった記憶がある

つか、rollbackにしろなんにしろ、こうであるっていう前提で明示的にしないほうがアレだろ
むしろ明示することのデメリットを知りたいわ
DBによっちゃオートコミットとかの設定がされてて全く逆の事になる場合だってあるだろっていう

896 :仕様書無しさん:2011/05/14(土) 00:08:05.30
あ、もちろんクライアントの数が不特定でそれなりに数あるってやつなw

897 :仕様書無しさん:2011/05/14(土) 00:15:38.23
なんか変なこと書いたな。オートコミットは毎回コミットだからこの話には関係はないわな忘れてくれ

898 :仕様書無しさん:2011/05/14(土) 12:13:05.13
>>895
 明示したいかどうかはどうでもいいんだけど、ここのスレって眺めてると例外の使用例にやたら
rollbackが多い気がすんだよ。だから、さもrollbackが重大な処理で例外処理なら
rollback(もしくはリソース開放)みたいなレスにクギを刺しとこうかと思ってね。
そこは例外の重要な用途でも本質でもないからこだわんなと。

899 :仕様書無しさん:2011/05/14(土) 20:50:50.74
ロールバック、リソース開放ごときに例外を使うなってこと?
それとも、もっと多彩な例を挙げろという要求?

いまいち意図がみえない

900 :仕様書無しさん:2011/05/14(土) 21:49:52.62
具体的にrollbackなんかより実用的で多彩な例をあげろって事。

901 :uy:2011/05/15(日) 02:07:50.13
例外って、ほんとに使いやすいの? やたらあちこちに例外使ってる奴いるけど
gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる
全てのエラーを例外使うんじゃなく適材適所が良い気がする

902 :仕様書無しさん:2011/05/15(日) 02:13:58.65
学生時代にgoto駄目だって習ったけど、小さい関数内で一個つかうくらいなら、べつによくねって感じで使ってることあるわ

903 :仕様書無しさん:2011/05/15(日) 02:56:30.80
>>898
rollbackはどうでもいいんだけど、ここのスレって眺めてるとやたらバカが多い気がすんだよ。
>rollback(もしくはリソース開放)みたいなレスにクギを刺しとこうかと思ってね。
リソースは開放じゃなく解放だから、ちゃんとクギを刺しとこうかと思ってねw
あと、899,900も日本語がおかしいw

904 :仕様書無しさん:2011/05/15(日) 11:51:20.13
>>901
goto禁止はまぁスルーしとくことにしてだな、
その理屈だとifやforやwhileによるジャンプも気になってこないかね?

905 :仕様書無しさん:2011/05/15(日) 15:13:08.33
>>904
その内容だと
レスつける相手間違ってる気がする

906 :仕様書無しさん:2011/05/15(日) 17:07:59.04
異常時の処理抜けにも便利よ
きちんと設計されてれば業務系の例外も綺麗に処理できるし、
各機能を実装する側も難しく考えないでルールに沿って例外投げるだけで
あとはお任せな形になるから、便利

ただ、きちんと設計ができてて、正しく使いきれてるプロジェクトはほっとんど見ないわw
分岐とループと関数さえわかってれば、同じ機能は作れてはしまうからな

907 :仕様書無しさん:2011/05/15(日) 17:39:06.83
>>898
リソースの解放は重要なことというのは間違いなくて、
リソースの解放をrollbackでやるか
disconnectでやるかの違いだけだろ?



908 :仕様書無しさん:2011/05/15(日) 17:43:12.63
データベースの処理で異常が発生したとき、
いちいちdisconnectなんかしてると汎用性がないってだけ。

いろんな場合を考えないといけないから
コードが複雑になる。

909 :仕様書無しさん:2011/05/15(日) 18:03:13.71
下手に汎用性持たせようとして失敗してるパターン?

910 :仕様書無しさん:2011/05/15(日) 18:12:22.30
rollbackすればそこで確保されていた更新排他なんかも開放されるけど
新しくコネクションひらいたら、ものによったら全部終わるまでそのまま残ったりするよね
アホじゃね

911 :仕様書無しさん:2011/05/15(日) 21:59:25.68
>>901
 例外やreturnなんかは、処理の入れ子を巻き戻してるだけだから
goto問題の範疇に入らない。言語設計側もそういう認識で作ってる。
 そもそもgotoがダメって認識が、認識不足。
ダイクストラの本はタイトルはgoto不要とは書いてあるが、
中身は、サブルーチンの入れ子を無視したジャンプをするなという事が
書いてある。アセンブリコードを読むときも、処理の入れ子を守ってるコードと
無視したコードは読みやすさが段違いだ。よってgotoと同じようにジャンプするから
使わない方がいいという理解は間違ってる。

912 :仕様書無しさん:2011/05/15(日) 22:01:05.55
>>910
>>892

913 :仕様書無しさん:2011/05/15(日) 22:10:30.78
>>910
新しくコネクション開いたらの意味が解らん。
同じDBへの接続を複数つくるのか?

914 :仕様書無しさん:2011/05/15(日) 22:18:13.71
>>907
切断ならfinallyないしデストラクターだけで済むけどな。
すくなくともこれで例外時に如何にrollbackするか議論に時間を掛ける必要性はなくなると思うが?

915 :仕様書無しさん:2011/05/15(日) 22:20:10.42
>>901
別スレでこいつのレス見たらキ○ガイだったわ。
真面目にレスして損した。

916 :仕様書無しさん:2011/05/15(日) 22:23:31.51
VBではエラー処理にGoto使うのは通例だしなぁ

917 :仕様書無しさん:2011/05/16(月) 00:31:07.51
Try

Shell("hoge.exe", AppWinStyle.Hide, False)

Catch ex As FileNotFoundException

MsgBox("hoge.exe doesn't exist.")

End Try

918 :仕様書無しさん:2011/05/16(月) 00:34:52.94
Dim apppath As String = "hoge.exe"

Try

Shell(apppath, AppWinStyle.Hide, False)

Catch ex As FileNotFoundException

MsgBox(apppath & " doesn't exist.")

End Try

のほうが良かったかもしれない

919 :uy:2011/05/16(月) 02:23:46.87
>>911
はぁ?
「gotoが使わないほうが良い」というのが今の世の中の流れだ
俺が個人的な意見として「goto使うな」とか一言もいっていない

おk?


で、俺が言ってるのは、
全てのエラー処理を例外で書く理由はないといってる
例外の中に例外がネストしてるソースとか読みにくくてバカかと思ったから。
例外を使わなくちゃいけないっていうルールに縛られた結果がそういうソースになるんだろ

920 :仕様書無しさん:2011/05/16(月) 07:31:15.30
>>919
へー、揚げ足取りたか無いけど、じゃあ日本語がおかしいんだな。

>例外って、ほんとに使いやすいの? やたらあちこちに例外使ってる奴いるけど
>gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
>例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる

正しいって事だよ。ここだけ見ればお前はgotoの肯定はしていない事がわかる。
肯定してる事は全く伝わらん。

>全てのエラーを例外使うんじゃなく適材適所が良い気がする

最後のこの文をみても、gotoも肯定してる立場だと読み取れる要素は全くない。

人は存在する文脈から相手の考えを察しようとするんで、肯定に懐疑的な文章を読んで、
「否定を一言も言っていない」を脳内補完するヤツはいない。

921 :仕様書無しさん:2011/05/16(月) 08:59:25.23
リアルでひとと話すことがないようなニートに日本語力期待するお前が悪い

922 :uy:2011/05/17(火) 07:15:00.25
>>920
はぁ?www
C言語で「「例外処理実装のためにgoto使うのが正しい」」って言っているのか

話になんねえwwwwwwwwwwwwwwww
勝手に現場で一人それをかいてクビになれwwwwwwwwww

923 :uy:2011/05/17(火) 07:18:56.81
>人は存在する文脈から相手の考えを察しようとするんで、肯定に懐疑的な文章を読んで、
>「否定を一言も言っていない」を脳内補完するヤツはいない。

君は勝手に脳内保管しちゃったことを認めるべき

文章を読む力がなさ過ぎる・・・・


人は存在する文脈から相手の考えを察しようとするんで(キリ)ww

924 :uy:2011/05/17(火) 07:21:57.45



人は存在する文脈から相手の考えを察しようとするんで(キリ)ww



人は存在する文脈から相手の考えを察しようとするんで(キリ)ww



人は存在する文脈から相手の考えを察しようとするんで(キリ)ww



人は存在する文脈から相手の考えを察しようとするんで(キリ)ww

925 :uy:2011/05/17(火) 07:29:03.35
そもそも、
> 例外やreturnなんかは、処理の入れ子を巻き戻してるだけだから
実装によるwwwwww おめーが見た言語のアセンブリコードでかたってんじゃねえよwwwにわかwwwwww

>言語設計側もそういう認識で作ってる。
意味不明www妄想乙すぎるwwwwwwwwwwwwww

> そもそもgotoがダメって認識が、認識不足。
>>901 を 100回よめ? 

>ダイクストラの本はタイトルはgoto不要とは書いてあるが、
そんな話してない

>中身は、サブルーチンの入れ子を無視したジャンプをするなという事が
そんな話してない

>書いてある。アセンブリコードを読むときも、処理の入れ子を守ってるコードと
そんな話してない

>無視したコードは読みやすさが段違いだ。よってgotoと同じようにジャンプするから
そんな話してない

>使わない方がいいという理解は間違ってる。
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
 そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
 そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない



926 :uy:2011/05/17(火) 07:35:09.32
>へー、揚げ足取りたか無いけど、じゃあ日本語がおかしいんだな。
既に>>911のレスからお前のレスは浮きまくりだよ


>>例外って、ほんとに使いやすいの? やたらあちこちに例外使ってる奴いるけど
>>gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
>>例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる
>正しいって事だよ。ここだけ見ればお前はgotoの肯定はしていない事がわかる。
はあ?www 俺は例外を否定してるんだよwwwwwwwwwwwwwwwwgotoの話してんのお前だけww

>全てのエラーを例外使うんじゃなく適材適所が良い気がする
>最後のこの文をみても、gotoも肯定してる立場だと読み取れる要素は全くない。
^^;;;

>人は存在する文脈から相手の考えを察しようとするんで、肯定に懐疑的な文章を読んで、
>「否定を一言も言っていない」を脳内補完するヤツはいない。

キリッ

また妄想で 人は〜 人は〜 って語っちゃって・・・・・・ひどい妄想癖だね・・・ きっも



にわかに知識つけて(キリッ)としながらレスつける相手を間違える奴をゴミと呼ぶ
最近じゃ殆ど誰も触ってなどいないアセンブラの話題を、こーんな場所でちらつかせるあたりがもう、
俺は細部まで知ってるぜ( ← そんな気になっちゃってるだけ ) アピールっつうか・・・ 寒い奴だな・・・・
人は存在する文脈から相手の考えを察しようとするんで(キリ)ww

927 :仕様書無しさん:2011/05/17(火) 08:22:44.86
>920はキチガイにマジレスした責任をとって最後まで相手するように

928 :uy:2011/05/17(火) 09:01:55.35
やっぱりプログラマってゴミだったんだな・・・・・・・・・・・・・・・・・・・・・

929 :uy:2011/05/17(火) 09:12:46.40
http://ja.wikipedia.org/wiki/%E3%81%94%E3%81%BF_%28%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%29

↑ 追加希望

  3、知識もないのに知ったかぶってレス書き込み時に、単語単位(スレッドなど)から読解する事が出来なくなったプログラマ(『ゴミグラマ』も参照)。

  4、ゴミグラマ(http://hibari.2ch.net/test/read.cgi/prog/1298059471/200)のこと

930 :uy:2011/05/17(火) 09:13:53.76
うはwwwwwwww レス番ミスったwwwwwwww

931 :仕様書無しさん:2011/05/17(火) 15:12:46.25
ここは社会から、例外処理される奴の吹き溜まりかw

932 :仕様書無しさん:2011/05/17(火) 15:40:17.83
finally

933 :仕様書無しさん:2011/05/17(火) 19:17:03.58
uyはユッケでも食って落ち着けw

934 :仕様書無しさん:2011/05/17(火) 19:58:15.50
おまえがそう思うんなら、そうなんだろう。
お前の中ではな。

中学で学年総シカトされたうえ、高校に進学できずニートになった
マジ○チくんと同じ臭いがする。何か親コロした上実家に火を放ちそうな
ファビョり具合だな。

935 :uy:2011/05/18(水) 17:23:33.31
実際これでも譲歩してんのに

 例 外 っ て な ん だ よ wwwwwwwwwwwwwwwwwwwwwwwww

環境( OSと言語 )がサポートしろバカwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww


そんなゴミグラミングをしている君たちは本当に可愛そうだ

どこぞのハッカー1人が、まじめに、OS、言語を作ってくれたら
そんな問題から開放されるのに
ハッカーさんは自分のためにしか力を使わないからねwwwwwwwwwwwwwwwwwwwwwwwwww
金を詰まれてもやる気しないwwwwwwwwwwwwwwwww
Time is 金wwwwwwwwwwwwwwww

936 :uy:2011/05/18(水) 17:27:57.98
だからほんとプギャーwwww なんですよ

根底部分が、しょっぼい実装をしているせいで、 それを補うプログラミングをしちゃってる君ら・・・・
よくやってられるね、幸せに仕事、プログラミング、プログラマ、したいやつは、気づいちゃいけない事実だけどさ

もしC言語のデリミタが ; が ;; だったらどうする?wwwwwwwwww
そういう事だよwwwwwww 俺が、ひとつ願いをかなえられるなら
C言語の ; を ;;;;; 規約にしてやろうかなwwwwwwwwwwwwwww
;;;; 4つじゃコンパイルエラーwww ;;;;; 5個つけないとダメwwwwwwwwwwwwっうぇwwww

環境にwwwwwwwwww振り回されるwwwwwwwww 君らwwwwwwwwwww

そwうwいwうwこwwとwだwwwよwwwwwwww

937 :仕様書無しさん:2011/05/18(水) 21:26:52.49
バカが、さわんじゃねーよ…

938 :uy:2011/05/18(水) 21:39:56.00
え?


  ┌──┐  ー--  _|__ ヽ         ┌┐  ┌┐  ──-   ー--  _|__ ヽ
  lニニニ|   -─┐   |      |   \   匚l   . 匚|         -─┐   |      |   \
  └┬┬┘    /   ノ   |    |    |  | ‐Eヨ ̄|          /   ノ   |    |     |
   ノ  |_ノ /⌒l_   <フ\  レ        | ┴┼ | (___ /⌒l_   <フ\  レ



939 :仕様書無しさん:2011/05/19(木) 00:24:53.00
こいつは速攻でNGNameに登録できるから別に害はないだろ

940 :u       y:2011/05/19(木) 10:22:38.92
>>939
死ねよ^^

941 :仕様書無しさん:2011/05/19(木) 12:29:15.14
またレス番飛んでる

942 :仕様書無しさん:2011/05/20(金) 03:58:06.36
gotoを使う場合は、頑張ればできる。
例外を使えば、簡単にできる。

できるできないの話はしていない。
どちらでもできる。当たり前。
簡単かどうかの話をしている。

943 :仕様書無しさん:2011/05/20(金) 11:31:22.19
gotoと一緒くたにしてる人まだいたのね
理解できないバカが例外はgotoとおなじで
どこに行くかわからないとかほざいてるのたまに聞くけど、ネタだと思ってたわw

944 :仕様書無しさん:2011/05/20(金) 11:49:37.28
come fromだよなw

945 :仕様書無しさん:2011/05/20(金) 17:51:40.29
例外と比べるなら、クロージャのほうが近い。
gotoと比べるなら、breakやcontinueのほうが近い。

946 :uy:2011/05/20(金) 21:13:54.65
俺が例外。


単純なロジックしか書いていないからわからないんだろうな・・・
まぁ、「例外」っていう概念に、俺がそこまでの負荷チェックをしてる事が間違っているのかな
未完成概念でも、現在君らがやってるプログラミング上では
なんら問題なく記述できるんなら、好きにかくといいよ


947 :仕様書無しさん:2011/05/21(土) 06:53:50.52
例外はハンドラ設定はほぼノーコスト。

948 :uy:2011/05/21(土) 08:44:02.66
こうやって、
授業料もらっているわけでもなく、無償で忠告を与えているにもかかわらず
それを聞かないからいつまでたってもゴミなんだよねお前ら

949 :仕様書無しさん:2011/05/21(土) 23:37:20.02
ゴミニートには税金経由で金恵んでやってるじゃないか
感謝しろよ

950 :仕様書無しさん:2011/05/21(土) 23:51:48.62
税金経由だと、中抜きされるから
直接金をくれなイカ

951 :uy:2011/05/23(月) 13:25:33.41
>>949
フリーのジャーナリストをやっています
今は活動休止中です

952 :仕様書無しさん:2011/05/23(月) 17:07:24.92
ニートかよw

953 :仕様書無しさん:2011/05/23(月) 21:31:33.44
コンサルやってる俺が書いてやるよ。

例外はメソッドの事後条件を満たせない場合にのみスローしろ。

メソッド内でnullチェックやってようが、他のチェックやっていようが事後条件を満たせない場合にだけスローしろ。

呼び出し元は呼び出し先がどんなチェックしてるか知っている必要はない。

呼び出し元が予期してないから例外なのであって、呼び出し元で例外を意識して処理させるような設計は糞。

つまり検査例外なんてものはもっての他だ。

そんなものがスローされる条件がわかるなら、最初から投げられないように呼ぶほうがマシ。

954 :仕様書無しさん:2011/05/23(月) 21:37:51.82
DbC!DbC!

955 :仕様書無しさん:2011/05/23(月) 21:44:57.47
>>953
 散々既出だな。異論は無いけど。
ところで何のコンサルだい?例外なんて瑣末な事を考えなきゃいけない
コンサルなんて見たことは無いんだが。

956 :仕様書無しさん:2011/05/23(月) 21:50:13.36
 例外を語るヤツは禿の論文読んでるよな。
まさか基礎論も知らずに偉そうに講釈タレてるなんて事ないよな。当然。

Exception Safety: Concepts and Techniques
http://www2.research.att.com/~bs/except.pdf

957 :仕様書無しさん:2011/05/23(月) 22:09:41.25
>>956
なんて答えて欲しいんだ?

958 :仕様書無しさん:2011/05/23(月) 22:18:51.18
>>956
自分の言葉で語れないならハナから書き込むなよ

959 :仕様書無しさん:2011/05/24(火) 06:55:30.75
>>953
呼び出し元が予期してないのが例外ではなく
呼ばれた処理が継続できない状態だと判断したからの例外だろ
呼び元が何かを意識するような、呼び元依存のメソッド設計はアホじゃね
そういうの多いけど

呼ぶ側が例外処理をするのめんどくさい、っていう呼び元視点だとそうなるのかもしれないけど
まずその視点が間違ってると思うんだが

大体入力された値のチェックなんかで発生させるような例外は、
チェック漏れ=ただの不具合なんだし、RuntimeExceptionとかErrorなりアサーションなりでやればいいわけで
検査例外からは除外されてるのが普通だし、呼び元が補足意識しないといけないわけじゃないような

検査例外は throws Exception する馬鹿処理が1個でも混じってるだけで破綻するし
きちんとjavadocが書ける奴がいないと、throwsだけあってもぶっちゃけ意味がないから
コンパイル通らなくなる制限は邪魔以外の何者でもないと思うけどな

960 :仕様書無しさん:2011/05/24(火) 08:29:52.21
呼び出し元が予期するのは
例外のあるなしであって
例外の種類は原則として予期しない。

呼び出し元は、すべての呼び出しで
例外が発生する可能性があるという前提で作る。
だけど、例外の種類は問わない。
どんな種類の例外がきても大丈夫なようにつくる。

だから検査例外は必要ない。

961 :仕様書無しさん:2011/05/24(火) 15:54:04.76
この間 BOSS2(ドラマ)の中で犯人のコンピュータにハッキングするところで
ソースコードが表示されてて goto ってのがあったような気がする

962 :仕様書無しさん:2011/05/24(火) 21:20:16.70
>>960
それじゃ回復できるもんも回復できねぇだろボケェ
ディスク容量足りなくて例外発生したなら、別のディスクに書き込むか、
ユーザーに書き込み先を指定させる事ができるが、
メモリーが足りなくて例外発生してたなら、そんな事してもどうにもならん。
先に開放できるメモリーの開放が必要になる。
例外の種類を無視したらこういう区別ができねぇだろ。

963 :仕様書無しさん:2011/05/25(水) 01:08:55.04
>>962
「"原則として"予期しない」って書いただろ。

なにか特別扱いしたいエラーの時だけ
やればいいんだよ。

回復できる例外というのは
まさに例外。


964 :仕様書無しさん:2011/05/25(水) 07:14:04.77
>>963
チェック例外で回復できない例外って何?
あと、本格的に例外処理しないにしても、
例外を受け取ったコールスタックで判断できる
情報を追加して例外を投げなおすぐらいは
必須だと思うけど。(例えば、writeでPermissonErrorが
発生したら、今開いているファイル名を負荷した
PermissionErrorを作り直して投げる)

965 :仕様書無しさん:2011/05/25(水) 20:56:41.99
>>960
そりゃ全ての処理の大元なんかが意識すればいいことだろ
だが、んなとこでできる復旧なんて、最初からやり直しだとかそういうレベルの
どうしても手に負えなかったような例外だけだっつー

必要のない場所でまで catch (Exception e) とかやってたらただの馬鹿だぞ?
予期せぬ不具合までもみ消しを起こす可能性生む糞コード
だいたい、検査例外って、回復手段はいくつか想定できるが、
どうしたいかは呼び元によるような場合に発生すんのが殆どじゃねーか
どんな例外が起こるか知らないで、どうするんだっていう

そりゃ、最終的にはどんな例外でも復旧すべきなのは、言うまでもなく当たり前の話だけど
んなこと意識するのは大元のほう担当する奴だけ
そういうのやる奴は最低限このあたりの事くらい理解してるだろうから、
960みたいな馬鹿発言しねーと思うんだけどな
…もしかして、一人で全部作るような小規模なプログラムの話してたのかな?

まーあれだよ
処理の端々で全部の例外キャッチするようなコードを書く奴が絶えないのも
throws Exceptionってかかれた糞メソッドを生み出す馬鹿がいるせいだとは思うけどな

んなことするくらいなら、最初から検査例外のない言語で作れよって言いたいわー

966 :仕様書無しさん:2011/05/26(木) 02:17:14.62
>>964
> チェック例外で回復できない例外って何?

仕様に書いてないものすべて

「そういう状態は考えなくていい」と言われたとしても
コードは書いているように動く。
どちらかで書かないといけない。

967 :仕様書無しさん:2011/05/26(木) 21:29:02.74
>>966
ぞんざいな職場だな。派遣?
仕様に詳細が無くとも例外の発生原因はメッセージに出すぞ。
レビュー時の指摘事項になってる。
揉み消したり、例外メッセージを
そのままでだしたりしたら信用に関わるからな。
あと外部設計に関わらない範囲なら現場の判断で、
できるだけリカバリーを取る。

968 :仕様書無しさん:2011/05/27(金) 02:05:32.96
横からだが、点数をつけてやるよ。
設計能力は>>966が60点 >>967が30点ぐらいだな。
今回は甘めの点数にした。正直967は初心者クラスだな。
966も967相手だからかなり点数を甘くしただけだから。

969 :仕様書無しさん:2011/05/27(金) 03:10:47.58
>>967
> 仕様に詳細が無くとも例外の発生原因はメッセージに出すぞ。

だからそういうこと。

仕様に詳細が無い物。それは無限にある。
書いてあるものは数が限られているが、
それ以外は数が限定できない。

そういう未知のものに対応するコードが書いてあるのなら、
チェック例外であっても基本的にはそのコードで対応できるはず。

だから、特別扱いしたい例外だけ捉えれば済むので
チェック例外の意味がないわけ。

970 :uy:2011/05/27(金) 13:56:13.26
例外に頼りすぎなんだよ

緊急地震速報 毎日のように垂れ流されたら、なにが緊急なのかわけわかんなくなるだろ

例外ってどれが例外だよ

971 :仕様書無しさん:2011/05/27(金) 18:09:33.61
次スレ
http://kamome.2ch.net/test/read.cgi/download/1288748104/


972 :仕様書無しさん:2011/05/27(金) 21:40:34.51
>>969
発生原因は、getMessage()やらmessage()やらで取れる文字列の事じゃないんだけどな。
日本語でかつ、ユーザーが見て何をどう変えればいいか判断できる内容だ。
例えば、「ホストに繋げませんでした」じゃユーザーはどうしようもない。

「ホストに接続できませんでした。
詳細:XXXX番ポートを使用できず接続できませんでした。
ファイアウォールやOSの設定で、XXXX番ポートの使用が
制限されていないかご確認下さい。」

というようなできるだけ対処可能な情報提供が必要。
でこの情報を出すには、例外に、ポートが原因だという型情報と、
ポートの何番が問題になったかを載せておく必要がある。
とりあえず戻り値を-1で返して、例外情報をGetLastErrorみたいな
形で返すならともかく、タダのエラーコードじゃユーザーは、
「またどこがおかしいのか調べなきゃいけないのか、
問い合わせるの面倒くせぇ、今度の発注先変えるか」つう事になる。

973 :仕様書無しさん:2011/05/27(金) 23:38:49.28
>>972
だからなんなんだよ?

例外を使うプログラミングに置いて
そういう情報提供をするのは例外を送信する側の仕事。

もし標準の情報が物足りないと判断したら、
その時は特別扱いして、例外をキャッチし情報を追加し、
また例外として再送出する。

すべての例外に詳しい情報を作成するのは開発工数的に無理。
つまり「こういう場合には詳しい情報を出す」という仕様が必要
仕様が暗黙の了解で済むような、ちゃらんぽらんな会社ならご愁傷さま。

だから、

デフォルトではなにもしない。(メッセージを追加したいなどの)
特別扱いしたい例外だけ捉えれば済む。という全く同じ結論になる。


974 :uy:2011/05/28(土) 03:05:54.86

べつによいのですよ?
わたくしの擁護をなさらなくても
じぶんのただしさはじぶんが一番よくしっております

それとも、uy勢力に加わる?

975 :仕様書無しさん:2011/05/28(土) 03:07:08.18
自信があるのなら、わざわざそんな負け惜しみを言わなくていいじゃないw

976 :仕様書無しさん:2011/05/28(土) 15:48:36.28
なんか流れがチェック例外の話から脱線してきてるようにも思えるけど、
チェック例外で回復できない例外は基本的にないでしょ。
外設に影響しない部分は、内部でルール決めて処理するか、仕様漏れを指摘して外設に追記依頼するのが普通だしな。

仕様にないものは回復できないって、そりゃ仕様バグだ。
基本設計だか詳細設計だかでの考慮漏れ、リリース前には修正するだろ。

>>969
> そういう未知のものに対応するコードが書いてあるのなら、
> チェック例外であっても基本的にはそのコードで対応できるはず。

そういう未知のものに対応するコードを書くような場所で補足しても、既に処理抜けて手遅れだろ。
もっと手前の発生場所の近くで補足して、回復するか、処理済の例外としてラップするのが普通。
それともあれか。
複数のメソッドに catch (Exception e)、handleException(e)みたいなコード埋め込むのが
正しいやり方だって主張したいん?

チェック例外は戻り値のチェックと同じ話だよ。
戻り値のフラグを意図的に無視したのか、チェック漏れかがわからない。
しかし例外なら無視はできないから必ずコードで表現する必要がある。

チェック例外の場合は、特別扱いしたくないものだから補足しなかったのか、
補足わすれたバグなのかがコードから判断つかないから、補足を必須にして、
無視したいなら無視したことがわかるようコーディングしろ。
それがチェック例外の目的でしょ。

まー、チェック例外は"全員がきちんと使っていれば"、補足漏れがなくなって便利ってだけ。
実際は、きちんと使えない馬鹿が1人混ざっただけで全部破綻するからいらない、っていう話はちょくちょく出るけどなw

>>967
悲しいことに、そういうぞんざいな職場は腐るほどあるよ。
っていうかまともにやってるとこを見かけるほうが割りと稀だったりするわ…。

977 :仕様書無しさん:2011/05/28(土) 17:19:46.02
> チェック例外で回復できない例外は基本的にないでしょ。

回復できないかどうかという、可能かどうかという話しは関係なく、

実際に回復するかどうかの話。
回復可能であっても回復しないこともある。
それは仕様による。すべてのチェック例外を回復させるわけじゃない。

また非チェック例外でも回復させることもある。

このように、チェック例外と非チェック例外で
区別することが何も無いのだから
チェック例外の必要性がない。

978 :仕様書無しさん:2011/05/28(土) 17:27:24.25
ライブラリのようなものが、 チェック例外を発生させるのが
間違いなのでは? つまりJavaの標準ライブラリなどは
チェック例外を発生してはいけない。

チェック例外はビジネスロジックを作る側が発生させる物。

ライブラリを使用している側が、
ライブラリが発生した非チェック例外を捉えて、
チェック例外に変換して、再発生させるよう形に
限定して使ううべき。

チェック例外は、そのアプリ専用の例外となる。

ライブラリを使用したライブラリは、ライブラリなので
もちろんチェック例外を使ったらいけません。

979 :仕様書無しさん:2011/05/29(日) 01:44:43.22
>>978
 try-catch書き忘れてコンパイラに怒られた経験は?
コンパイラに指摘されて、処理し忘れた事に気づくことは多々ある。
例外処理を入れなきゃならないとわかってていても、
コード書いた時は忘れてる事が多い。コンパイル時の
型チェックによって構文ミスに気づくのと同じことだ。
 まぁ、いまどきの子はEclipseがあるしコマンドライン中心で
コード書いた事無いから解らんのだろうけど。
それでもチェック例外で例外処理を書き忘れないという恩恵には
与れているはずだが。

980 :仕様書無しさん:2011/05/29(日) 01:57:39.50
>>979
えとな、コンパイラに怒られて書くコードが
すべて同じになるんだよ。
エラーを再送出するという同じコードに。

このエラーの時は特別な処理をしたいなって思うときは
コードを書くのを忘れない。
それ以外はすべて同じコード。

チェック例外は単にテンプレを書かされてるだけ。
それに一体何の意味があるんだよ。

981 :仕様書無しさん:2011/05/29(日) 02:21:47.02
>>980
 あ?例外仕様に追記するか、
catchで別の例外生成するかだろ。
例外仕様への追記すら同じコード
でめんどうだといいたいのか?

982 :仕様書無しさん:2011/05/29(日) 02:28:42.72
例外仕様に追記って何だ?
関数の所に送出する例外を付け加えるアレか?

あれはいかん。関数のシグネチャが変わってしまう。
インターフェースには送出する例外を書いてないとき
実装だけを変えることができない。当たり前だが。

だから汎用的に使えるのはcatchで別の例外に置き換えるやりかただが、
わざわざ別の例外に変更するのは言うまでもなく面倒
どうせ自分の例外にラップして、再送出するという
同じコードを書くだけになるんだから。

983 :仕様書無しさん:2011/05/29(日) 02:51:01.06
>>982
例外仕様の仕組みをよく知らないだろ。

例えIOExceptionを例外仕様に書いてあっても、
IOExceptionしかcatchできない訳じゃない。
IOExceptionを継承しているクラスの名前をcatchに
書いてやれば例外仕様に書いてない例外を処理する事ができる。

i

984 :仕様書無しさん:2011/05/29(日) 02:59:02.55
>>982
メソッドの例外仕様には機能的なカテゴリを表す例外クラスを
書くのであって、具体的な例外クラスの名前を書くんじゃない。
だからもっとも抽象的な例外カテゴリをinterfaceに追記している限り、
interfaceのメソッドに書いてある例外仕様を書き換えなきゃならんなんて
事にはならない。


985 :仕様書無しさん:2011/05/29(日) 03:42:19.19
> 抽象的な例外カテゴリをinterfaceに追記している限り

だから全部にExceptionを書いた状態であればいい。

986 :仕様書無しさん:2011/05/29(日) 09:31:43.18
関数仕様にない例外が発生したという例外を発生させればいいだけ。

987 : 忍法帖【Lv=1,xxxP】 !:2011/05/29(日) 11:31:21.86
UnexpectedExceptionThrownExceptionThrownExceptionThrownException...

988 :仕様書無しさん:2011/05/29(日) 12:00:01.52
結局否定してる理由は、「面倒くさい」ってことなんでしょ。

面倒だからって理由で、意図が判断し辛いコードを書いて、
面倒だからって理由で、その意図をコメントとしては残さないやつが必ずいるから
判断し辛いコードにならないように、コーディングレベルで意図が明確になるようにする仕組みなんだから、
検査例外の目的は果たせてるってことじゃん。

989 :仕様書無しさん:2011/05/29(日) 12:02:24.33
違うな。

面倒なことをしても何のメリットもないのが問題。

結局コメントを書けばいいだけの話で
検査例外の必要性がない。

990 :仕様書無しさん:2011/05/29(日) 12:13:01.68
>>979へ戻る訳か。

991 :仕様書無しさん 忍法帖【Lv=3,xxxP】 :2011/05/29(日) 12:20:56.22
>>989
ちがわねーよ。本当に馬鹿なのか?
コメントは強制じゃないからルールを守らせるのは無理。
Javaの根底に再利用ができるコードってのがあるから、そういう面倒な仕組みになったんでしょ。
文句垂れるならそんな言語を選択しなけりゃ良いだけで、Javaを使う以上、言語仕様くらい守っとけ。

992 :仕様書無しさん:2011/05/29(日) 12:27:03.96
Javaの言語仕様に文句を付けている人がいるからこそ
Javaが進化し続けているというのを忘れるな。

993 :仕様書無しさん:2011/05/29(日) 12:52:42.89
javaの言語自体に文句はねーよ
でもプログラム組む前の前準備や周辺機器(ライブラリ?)は全環境中最悪だと言える
Eclipseお前だよ

994 :仕様書無しさん:2011/05/29(日) 13:03:01.29
>>989
まぁ、お前は専門卒と.net環境で楽しくプログラミングしてろよ。


995 :仕様書無しさん:2011/05/29(日) 13:07:39.01
Javaで有名な人も検査例外を否定していたよね。

996 :仕様書無しさん:2011/05/29(日) 13:32:40.76
>>995
IBMの記事か。
オブジェクト指向ですら否定していた有名人はいたよね。
Javaそのものを否定していた有名人もいたよね。


997 :仕様書無しさん:2011/05/29(日) 14:20:08.21
まー馬鹿が紛れ込んでて、どっかになに投げるかわからないからって
throws Exception って書かれてしまっていた案件はもう手遅れ状態になるし
他社製ライブラリとかがそういうことしてたりすると、検査例外の仕組みがほぼ死ぬから
そういう意味ではやっぱ邪魔だなとは思うよ
コンパイラ設定で警告にするかエラーにするか選べるとかあればよかったかもしれないな

つっても今やってるプロジェクトのソースは、警告だけで10k越えてて、
警告が全く意味なしてないのだけれどな/ ,' 3  `ヽーっ

998 :仕様書無しさん:2011/05/29(日) 14:20:39.70
とりあえず次スレ立ててきた

例外を正しく使えないプログラマ多いね。 その7
http://hibari.2ch.net/test/read.cgi/prog/1306646249/

999 :仕様書無しさん:2011/05/29(日) 14:21:19.64


1000 :仕様書無しさん:2011/05/29(日) 14:21:52.48


1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

259 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)