例外を正しく使えないプログラマ多いね。 その6
|
|
|
例外のおかしな使い方を見つけたら張るとか
こういう使い方してるの見たけど、こっちのほうがよくね？とか
そういう話題は例外的で、基本脱線議論を行う
ここはきっとそんなスレッドです
こういう使い方してるの見たけど、こっちのほうがよくね？とか
そういう話題は例外的で、基本脱線議論を行う
ここはきっとそんなスレッドです
try{
スレッドSercice.post>>1乙(thisThread);
} catch (糞スレException e) {
京大霊長類研究所Service.callアイちゃん(thisThread);
}
スレッドSercice.post>>1乙(thisThread);
} catch (糞スレException e) {
京大霊長類研究所Service.callアイちゃん(thisThread);
}
4 ：仕様書無しさん：2011/02/19(土) 08:14:26
早朝にスレ立てとか。 オマエ、学生か無職だろｗ
構って欲しくて仕方が無いんだな。
構って欲しくて仕方が無いんだな。
例外が発生しました
クラスUnexpectedException。場所>>4。内容：曜日感覚がありません
クラスUnexpectedException。場所>>4。内容：曜日感覚がありません
関数から戻り値はクリーンな値でなければならない。
もらった値はすぐに次の処理で使用できるべき。
つまり値として不正な物が含まれていてはいけない。
もらった値はすぐに次の処理で使用できるべき。
つまり値として不正な物が含まれていてはいけない。
7 ：仕様書無しさん：2011/02/19(土) 08:40:23
今日に限らないから言ってんだけどねｗ
一人のバカが遊ばれてるスレ
>>9
それは文化じゃなくて関数の仕様。
関数名が、parseではなくtryParseとなっていることに注意
その関数はparseするのではなく、tryする関数。
だからtryした戻り値はtryした結果になる。
tryParseの戻り値は、parseした結果が含まれることはなく、
tryした結果、つまり変換できるかできないかが返る。
やってはいけないのは、関数の戻り値に、値とエラーコードが混ざること。
tryParseは混ざってない。
それは文化じゃなくて関数の仕様。
関数名が、parseではなくtryParseとなっていることに注意
その関数はparseするのではなく、tryする関数。
だからtryした戻り値はtryした結果になる。
tryParseの戻り値は、parseした結果が含まれることはなく、
tryした結果、つまり変換できるかできないかが返る。
やってはいけないのは、関数の戻り値に、値とエラーコードが混ざること。
tryParseは混ざってない。
文字列を数値に変換するのに失敗したみたいな、作る時から予測可能なことで
いちいち例外処理させられるのは、無駄に長くてコードが見づらい
文字列を数値に変換できるか調べるメソッドを事前に呼べってことなのかもしれないが
いちいち例外処理させられるのは、無駄に長くてコードが見づらい
文字列を数値に変換できるか調べるメソッドを事前に呼べってことなのかもしれないが
>>11
例外を出したくないのなら、例外を出さなくていいんだよ。
tryParseみたいに、try○○って関数を作ればいい。
ただ戻り値に値とエラーコードを混ぜてはだめ。
だからといって、すべての関数にたいして
try○○をつくろうと思うなよｗ
スタックトレースの出力とか例外のほうが優れているんだし、
使うのは必要最小限にしとけ。
例外を出したくないのなら、例外を出さなくていいんだよ。
tryParseみたいに、try○○って関数を作ればいい。
ただ戻り値に値とエラーコードを混ぜてはだめ。
だからといって、すべての関数にたいして
try○○をつくろうと思うなよｗ
スタックトレースの出力とか例外のほうが優れているんだし、
使うのは必要最小限にしとけ。
関数の戻り値に値とエラーコードを混ぜないというのは、
int errorcode = func(param, &out_value);
もしくは、
int value = func(param, &out_errorcode);
のどちらかの形式を使えということ
tryParseはこれに従っている。
int value_or_errorcode = func(param);
これはいけない。変数名からしていやだろ？
int errorcode = func(param, &out_value);
もしくは、
int value = func(param, &out_errorcode);
のどちらかの形式を使えということ
tryParseはこれに従っている。
int value_or_errorcode = func(param);
これはいけない。変数名からしていやだろ？
例外はGOTO文と同じ。
tryの位置で割り込み例外が起きたら、ここへ飛べと書いているだけ。
GOTO文を多用するプログラマーは馬鹿だ。
例外が起きたら、やることは２つ「リカバリーとリソース保護」だ。
それ以外の処理を書く奴はアホだ。
tryの位置で割り込み例外が起きたら、ここへ飛べと書いているだけ。
GOTO文を多用するプログラマーは馬鹿だ。
例外が起きたら、やることは２つ「リカバリーとリソース保護」だ。
それ以外の処理を書く奴はアホだ。
>>14
例外とgotoはぜんぜん違う。
例外はエラー処理にしか使わない。
gotoと違って前の処理に戻らない。
gotoをエラー処理になら利用しても良いという考えに
したがって作られたものと言える。
例外とgotoはぜんぜん違う。
例外はエラー処理にしか使わない。
gotoと違って前の処理に戻らない。
gotoをエラー処理になら利用しても良いという考えに
したがって作られたものと言える。
.NETのTryParseはParse結果もセットしてくれるけどな。
戻り値はtry結果だけど。
戻り値はtry結果だけど。
>>16
parse結果とtry結果を混ぜてないからOK
parse結果とtry結果を混ぜてないからOK
何を長々と語っとるんだこのアホは
お前も語ることがあるなら語っていいんだよ。
反論がないと面白くないｗ
反論がないと面白くないｗ
>>20
throwすればいいじゃん？
throwすればいいじゃん？
gotoは絶対悪なんじゃなくてそれこそ
「gotoを正しく使えないプログラマ多いね」って状態になりやすいから原則禁止にして、
よく使うパターンに関してはbreakやcontinueのような専用の命令を導入してる。
「gotoを正しく使えないプログラマ多いね」って状態になりやすいから原則禁止にして、
よく使うパターンに関してはbreakやcontinueのような専用の命令を導入してる。
そのbreakとcontinueでもやれないこと、
つまりエラー処理のためのgotoの代わりになる
専用の命令が例外なんだ。
つまりエラー処理のためのgotoの代わりになる
専用の命令が例外なんだ。
例外を備えることによって、
本当にgotoをなくすことに成功したよな。
本当にgotoをなくすことに成功したよな。
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はいらない)
メソッド(関数名): 自由につけろ
メソッド(関数)の型: 自由に考えろ
メソッドに渡す引数: 自由に考えろ
おこりうるエラーと捕獲するべき例外:自由に考えろ
さあ作ってみろ。馬鹿どもよ。
なんだよ、誰も擬似コードすら書けないのかよ、んとに馬鹿ぞろいだな
なんか具体的な例がないからいかんのだな
例外化の学習
テーマ「メソッドの設計」
言語、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;
こうすりゃあいいだろう、お前馬鹿だな
if(!checkXXX()){
msg = "うんこがもれそうです";
flg = FALSE;
goto ERROR;
}
・
done:
if(!flg) MessageBox(msg);
return flg;
こうすりゃあいいだろう、お前馬鹿だな
>>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)
}
例外の場合は、処理を飛ばすだけじゃなくてオブジェクトを渡せる。
だから
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; なスマソ
こうすることで、ユーザーインターフェース部分（メッセージボックス）を
処理と分離することが可能で、もしこれがコンソールなら簡単にprintfに置き換えられるだろう。
また、スタックトレース（関数の呼出履歴やエラーが発生した行番号）を
ログファイルに出力することもできる。
これは、例外を使わない場合は自分で作りこまなければわからない情報。
処理と分離することが可能で、もしこれがコンソールなら簡単にprintfに置き換えられるだろう。
また、スタックトレース（関数の呼出履歴やエラーが発生した行番号）を
ログファイルに出力することもできる。
これは、例外を使わない場合は自分で作りこまなければわからない情報。
31 ：仕様書無しさん：2011/02/19(土) 12:21:40
>>30
うえせえよ、おじゃば!!
うえせえよ、おじゃば!!
うえせえなぁｗ
33 ：仕様書無しさん：2011/02/19(土) 12:24:07
>>32
お前、どうせ言い回しで於邪婆ってわかるんだからコテつけろw
お前、どうせ言い回しで於邪婆ってわかるんだからコテつけろw
わかるならコテいらないよ。
35 ：仕様書無しさん：2011/02/19(土) 12:26:34
おじゃばさまとは (unkopedia)
かつて69式オッサンスレとかで、その人柄とダサイ思考回路が大人気だった
人です
かつて69式オッサンスレとかで、その人柄とダサイ思考回路が大人気だった
人です
36 ：おじゃば ◆hMIVgvHpWk ：2011/02/19(土) 12:29:55
37 ：仕様書無しさん：2011/02/19(土) 12:30:03
しっかし、相変わらずくどくどしいコード書いてからに・・・
スキルが全くあがってないのはある意味おじゃばらしいな
スキルが全くあがってないのはある意味おじゃばらしいな
つーことで、コテ付いてない俺は
おじゃばじゃないということですね
おじゃばじゃないということですね
39 ：仕様書無しさん：2011/02/19(土) 12:31:15
それと、相変わらず「業務システム」に特化しているようだなw
わざと非常識な事を言って、屁理屈付けて他人をからかってんのか。
しょーもないやっちゃな
しょーもないやっちゃな
41 ：仕様書無しさん：2011/02/19(土) 12:32:49
真のおじゃばは 「おじゃばさま」のみで◆トリップはなしだ
43 ：仕様書無しさん：2011/02/19(土) 12:33:40
>>42 MessageBoxを出すWebシステムですか? 革新的ですなあ
45 ：仕様書無しさん：2011/02/19(土) 12:35:15
>>45
あなたは150歩ぐらいですか？
あなたは150歩ぐらいですか？
47 ：仕様書無しさん：2011/02/19(土) 12:37:52
もしかして、「はつみみです」の人？
50 ：仕様書無しさん：2011/02/19(土) 12:42:09
>>49 だから不要な箇所は省いていいよ。
俺がサンプル出したら設計にならないだろう
繰り返して言うけど、省くとこは省いても良い、完全なコンパイルコードで
無くとも良い、擬似コードレベルでも良い
それを見ると君のレベルが分かるからさ
俺がサンプル出したら設計にならないだろう
繰り返して言うけど、省くとこは省いても良い、完全なコンパイルコードで
無くとも良い、擬似コードレベルでも良い
それを見ると君のレベルが分かるからさ
>>28
例外にエンドユーザに見せるための文字列を入れるのはクソ設計
例外にエンドユーザに見せるための文字列を入れるのはクソ設計
52 ：仕様書無しさん：2011/02/19(土) 12:44:39
>>51
そうねえ、MessageBoxでなくてシステムログに静かに記録するのがベターかな
そうねえ、MessageBoxでなくてシステムログに静かに記録するのがベターかな
>>50
じゃあ実際にHTMLを解釈するコードは不要だな。
$('input[name="NAME_HOGE"]').name = "REIGAI_SUKINA_AHO";
以上。
あ？言語の指定があったな。 JQueryを使ったJavaScriptコードはだめか？
document.getElementsBySelector("input[name=\"NAME_HOGE\"]").setName("REIGAI_SUKINA_AHO");
以上。
起こりうる例外は、セレクタ文法のエラーとか、
詳しくはJQueryのドキュメント見てくれ。
どうせ俺が書いてもコピペするだけだから。
じゃあ実際にHTMLを解釈するコードは不要だな。
$('input[name="NAME_HOGE"]').name = "REIGAI_SUKINA_AHO";
以上。
あ？言語の指定があったな。 JQueryを使ったJavaScriptコードはだめか？
document.getElementsBySelector("input[name=\"NAME_HOGE\"]").setName("REIGAI_SUKINA_AHO");
以上。
起こりうる例外は、セレクタ文法のエラーとか、
詳しくはJQueryのドキュメント見てくれ。
どうせ俺が書いてもコピペするだけだから。
55 ：仕様書無しさん：2011/02/19(土) 12:53:41
>>53
ぐはははははは、やっぱりそうきたか。
俺が示して欲しいのは文字列操作時に発生する問題をきちんとトラップした
設計だよ。あの設問からプロシステム屋ならば「なにが大事か」をすぐに分かるはず
だけどね。複数発生する例外をどう設計対応するかが大事。
せっかく作ってくれたけど、ほんとコードでなくてもいいし
考えられる「発生する例外の種類」を列挙してくれないかなあ
ぐはははははは、やっぱりそうきたか。
俺が示して欲しいのは文字列操作時に発生する問題をきちんとトラップした
設計だよ。あの設問からプロシステム屋ならば「なにが大事か」をすぐに分かるはず
だけどね。複数発生する例外をどう設計対応するかが大事。
せっかく作ってくれたけど、ほんとコードでなくてもいいし
考えられる「発生する例外の種類」を列挙してくれないかなあ
>>55
つまりどういうこと？
つまりどういうこと？
さて、気が狂ったアホは放っておいて、
例外と戻り値の話に戻ると、先の
$('input[name="NAME_HOGE"]').name = "REIGAI_SUKINA_AHO";
これ。凄くシンプルだけど、これ戻り値をエラー返す方式では使えないんだ。
なぜなら、$()関数 が戻り値をエラーで返すと、
[見つかった複数のエレメントオブジェクト].name = "REIGAI_SUKINA_AHO";
ではなく、
[エラー値オブジェクト].name = "REIGAI_SUKINA_AHO";
となってしまう。
この場合、全く意図しない動きになってしまうのはわかるよね？
例外が優れているのはこういう所。
例外と戻り値の話に戻ると、先の
$('input[name="NAME_HOGE"]').name = "REIGAI_SUKINA_AHO";
これ。凄くシンプルだけど、これ戻り値をエラー返す方式では使えないんだ。
なぜなら、$()関数 が戻り値をエラーで返すと、
[見つかった複数のエレメントオブジェクト].name = "REIGAI_SUKINA_AHO";
ではなく、
[エラー値オブジェクト].name = "REIGAI_SUKINA_AHO";
となってしまう。
この場合、全く意図しない動きになってしまうのはわかるよね？
例外が優れているのはこういう所。
例外処理中でメッセージボックス表示しちゃダメだって言うなら、
いつのタイミングで表示すればいいのさ？
いつのタイミングで表示すればいいのさ？
>>59
そりゃ、ユーザーインターフェース層じゃない？
そりゃ、ユーザーインターフェース層じゃない？
61 ：仕様書無しさん：2011/02/19(土) 13:13:14
>>56
ああ、すまないね。理解できないか、俺が悪かった。
ああ、すまないね。理解できないか、俺が悪かった。
62 ：仕様書無しさん：2011/02/19(土) 13:14:00
>考えられる「発生する例外の種類」を列挙
これが理解できないとは・・・ゆとりの人なのか・・
ごめんな
これが理解できないとは・・・ゆとりの人なのか・・
ごめんな
>>54
>なんで俺にだけ
お前の方だけ下位から上がって来たモンをそのままユーザに見せてるから。
MessageBox()を使うな、とは言ってない。
>>28 >そしてこのようなことができる。
について「そのようなことはすんな」っつってんの。
なんでe.getMessageを表示しようとするんだよ？
なんで例外を投げる方が「画面にどう表示するか」を意識せにゃならんの？
>それじゃあ、どう対処するかなんて・・・
対処せにゃならん、てところに思考が及んでないこと自体が問題。
>なんで俺にだけ
お前の方だけ下位から上がって来たモンをそのままユーザに見せてるから。
MessageBox()を使うな、とは言ってない。
>>28 >そしてこのようなことができる。
について「そのようなことはすんな」っつってんの。
なんでe.getMessageを表示しようとするんだよ？
なんで例外を投げる方が「画面にどう表示するか」を意識せにゃならんの？
>それじゃあ、どう対処するかなんて・・・
対処せにゃならん、てところに思考が及んでないこと自体が問題。
ﾜﾗﾀもう60かよｗ
>>63
> なんでe.getMessageを表示しようとするんだよ？
> なんで例外を投げる方が「画面にどう表示するか」を意識せにゃならんの？
例外投げる方は、ユーザー用のmessageをセットしてるだけだろ？
それを画面に表示するかは、例外を受け取った側（catch）が
やってることじゃん。コードよく見ろよ。
> なんでe.getMessageを表示しようとするんだよ？
> なんで例外を投げる方が「画面にどう表示するか」を意識せにゃならんの？
例外投げる方は、ユーザー用のmessageをセットしてるだけだろ？
それを画面に表示するかは、例外を受け取った側（catch）が
やってることじゃん。コードよく見ろよ。
>>65
その状況が既に設計をミスってる気がしなくもないけど、
言語環境によっては、インタラクティブな処理が要るなら、
同期イベントでコールバック的にUI層まで上がってから
例外処理まで戻って来れたりする。
その状況が既に設計をミスってる気がしなくもないけど、
言語環境によっては、インタラクティブな処理が要るなら、
同期イベントでコールバック的にUI層まで上がってから
例外処理まで戻って来れたりする。
>>68
要するに、ムリがあるんだよ。 みんなが同音異句に、そういう事を言ってる。
要するに、ムリがあるんだよ。 みんなが同音異句に、そういう事を言ってる。
すなおにcatchでメッセージボックスを表示しろってことですな。
もちろん、ユーザーインターフェース層のcatchでね。
もちろん、ユーザーインターフェース層のcatchでね。
しかしわかりやすい馬鹿だなぁ
俺が多数ｷﾘｯ
俺が多数ｷﾘｯ
俺が小数キリ？
俺もわかってて相手してるよｗ
本人だけでしょ気付いてないの…
本人だけでしょ気付いてないの…
しかしまあ、まともな反論がなくなったな。
言い負かしすぎたか？
言い負かしすぎたか？
例の本人さんがいなくなると、とたんに静かになるからね。
これだけ例外全盛期なのに、例外否定とか
わかってないだけじゃんだし。
これだけ例外全盛期なのに、例外否定とか
わかってないだけじゃんだし。
まともな事書こうとしても言い負かされるから、分かりやすい煽りしかしなくなってるしな。
じゃあ、世の中の決定的な意見をどうぞ。
例外はエラー処理が充実してます。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070925/282909/
> 最近はネットのコードでもエラー処理が充実しているのもあるが，やはりそれは例外。
例外はエラー処理が充実してます。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070925/282909/
> 最近はネットのコードでもエラー処理が充実しているのもあるが，やはりそれは例外。
whileのなかで
try catchをあたかも条件分のごとく使うソースを見たことがあるな
そのブロックが２kぐらいあって、読みきるのに時間かかった覚えがあった
try catchをあたかも条件分のごとく使うソースを見たことがあるな
そのブロックが２kぐらいあって、読みきるのに時間かかった覚えがあった
それはどっちかつーと例外より1ブロックに機能詰めすぎなのが問題なんじゃねｗ
コピペねぇ
うるせぇな。コピペの何が悪いんだよ
分からないでコピペしてるから
結局例外が悪いんじゃなくて、例外を正しく使えないやつがいるのが問題なだけだよな
んで、正しく使えてない例外のせいで例外が悪いと決め付けて学ばないやつが
悪い例外の使い方しない、っていう馬鹿のスパイラル
んで、正しく使えてない例外のせいで例外が悪いと決め付けて学ばないやつが
悪い例外の使い方しない、っていう馬鹿のスパイラル
例外を使う場合と使わない場合ではソフトウェアの構成までちがってくるよな。
たとえばメッセージを出すにしても、エラーが起きた情報ってのが知る必要がある。
たとえばファイルが開けなかったときのファイル名とか。
戻り値基本的にエラーがintとか単純な方だから、たとえばファイルを開けなかったという情報だけを返して、
そしてエラーを受け取った側がエラーメッセージに必要な情報をかき集める。
でも例外だと、ファイルが開けなかったという情報じゃなくエラーがオブジェクトだから、
様々な情報を付加できる。つまり、エラーを出す側がエラーの情報をかき集める。
ここまでがロジック部分で、それをどう表示するかは別のところで共通に処理することができる。
エラーのオブジェクトに必要な情報が含まれているから、メッセージを表示する段階では
シンプルに作ることが出来る。
たとえばメッセージを出すにしても、エラーが起きた情報ってのが知る必要がある。
たとえばファイルが開けなかったときのファイル名とか。
戻り値基本的にエラーがintとか単純な方だから、たとえばファイルを開けなかったという情報だけを返して、
そしてエラーを受け取った側がエラーメッセージに必要な情報をかき集める。
でも例外だと、ファイルが開けなかったという情報じゃなくエラーがオブジェクトだから、
様々な情報を付加できる。つまり、エラーを出す側がエラーの情報をかき集める。
ここまでがロジック部分で、それをどう表示するかは別のところで共通に処理することができる。
エラーのオブジェクトに必要な情報が含まれているから、メッセージを表示する段階では
シンプルに作ることが出来る。
>>88
えー、戻り値だって引数で詳細取得できるようにしたらかわんないじゃーん
俺は例外は明示的な記述ができないって１点だけがデメリットで
それがプロジェクト全体でかなり巨大な負債になってしまうことが嫌なだけなんだけどね
パッっとみてわかんないっしょ？
ドキュメントまでみないとなんの処理してるのかわからない
えー、戻り値だって引数で詳細取得できるようにしたらかわんないじゃーん
俺は例外は明示的な記述ができないって１点だけがデメリットで
それがプロジェクト全体でかなり巨大な負債になってしまうことが嫌なだけなんだけどね
パッっとみてわかんないっしょ？
ドキュメントまでみないとなんの処理してるのかわからない
>>81
>>25は表示メッセージを戻り値に設定するようなことはしてないからね。
わざわざ例外を投げ直すように変更する理由は
UIとロジックの分離だと見たし、妥当だと思うけど
結局分離出来て無いのが半端。
>>27は見てくれだけ世間を真似てみたけど
失敗した、と見える。
>>25がどうこう言うなら素直に1つめのcatchで
MessageBox()を呼んでおけよ。
それなら何も言わんよ。
>>25は表示メッセージを戻り値に設定するようなことはしてないからね。
わざわざ例外を投げ直すように変更する理由は
UIとロジックの分離だと見たし、妥当だと思うけど
結局分離出来て無いのが半端。
>>27は見てくれだけ世間を真似てみたけど
失敗した、と見える。
>>25がどうこう言うなら素直に1つめのcatchで
MessageBox()を呼んでおけよ。
それなら何も言わんよ。
>>92
俺はいつでもbool型
俺はいつでもbool型
>>89
わらかないのは仕様理解が不足してるからじゃ？
わらかないのは仕様理解が不足してるからじゃ？
>>90
> >>25は表示メッセージを戻り値に設定するようなことはしてないからね。
え？ だれが表示メッセージを戻り値に設定した？ｗ
どうやらゴールが見えてきたね
お前が赤っ恥をかくというゴールが。
> >>25は表示メッセージを戻り値に設定するようなことはしてないからね。
え？ だれが表示メッセージを戻り値に設定した？ｗ
どうやらゴールが見えてきたね
お前が赤っ恥をかくというゴールが。
>>93
それは要するにこの一番目のパターンだろ？
>>13
> 関数の戻り値に値とエラーコードを混ぜないというのは、
>
> int errorcode = func(param, &out_value);
>
> もしくは、
>
> int value = func(param, &out_errorcode);
>
> のどちらかの形式を使えということ
> tryParseはこれに従っている。
>
> int value_or_errorcode = func(param);
>
> これはいけない。変数名からしていやだろ？
それは要するにこの一番目のパターンだろ？
>>13
> 関数の戻り値に値とエラーコードを混ぜないというのは、
>
> int errorcode = func(param, &out_value);
>
> もしくは、
>
> int value = func(param, &out_errorcode);
>
> のどちらかの形式を使えということ
> tryParseはこれに従っている。
>
> int value_or_errorcode = func(param);
>
> これはいけない。変数名からしていやだろ？
>>94
戻り値なら理解できるのに例外はtryの中身全部しらべないと確認できないだろ
んで、大抵はドキュメントとソースが食い違ってて例外なんて誰も把握していないと
担当者のオナニーで終わってる宙ぶらりんな例外ばっかりなんだよこの世はｗ
戻り値なら理解できるのに例外はtryの中身全部しらべないと確認できないだろ
んで、大抵はドキュメントとソースが食い違ってて例外なんて誰も把握していないと
担当者のオナニーで終わってる宙ぶらりんな例外ばっかりなんだよこの世はｗ
もうわかったと思うけど、戻り値エラーの欠点の一つは、
このようにライブラリや方針によって
エラーをどう返すかがバラバラｎ所
このようにライブラリや方針によって
エラーをどう返すかがバラバラｎ所
>>95
下位が上位に対して通知するエラーの情報に
上位が表示したいメッセージを含めてない。
>>25はエラーを戻り値で通知してるが、戻り値に含めてない。
>>28はエラーを例外で通知してるが、例外に含めてる。
下位が上位に対して通知するエラーの情報に
上位が表示したいメッセージを含めてない。
>>25はエラーを戻り値で通知してるが、戻り値に含めてない。
>>28はエラーを例外で通知してるが、例外に含めてる。
どうでもいいような内容に...
>>103
どうやら気づいてないようだからｗ
ちゃんと言っておくね。>>28の略っていうのは
こういう意味だよ。
try {
try {
checkXXX();
} catch(Exception e) {
throw new MyException("XXXXXX", e);
}
} catch(MyException e) {
MessageBox(e.getMessage);
printlog(e)
}
はじめから、例外を関数外なんか投げてません。
どうやら気づいてないようだからｗ
ちゃんと言っておくね。>>28の略っていうのは
こういう意味だよ。
try {
try {
checkXXX();
} catch(Exception e) {
throw new MyException("XXXXXX", e);
}
} catch(MyException e) {
MessageBox(e.getMessage);
printlog(e)
}
はじめから、例外を関数外なんか投げてません。
>>107
そりゃそうだよ。
だって元々のコードが、エラーをチェックしたその場所で
メッセージを表示してるじゃん。
もともとのコードが悪い。
エラー値を返す前にエラーを表示しているという
クソコードなんだよ>>25は。
だから文句は>>25につけなさい。
そりゃそうだよ。
だって元々のコードが、エラーをチェックしたその場所で
メッセージを表示してるじゃん。
もともとのコードが悪い。
エラー値を返す前にエラーを表示しているという
クソコードなんだよ>>25は。
だから文句は>>25につけなさい。
ぶっちゃけひどい例外の使い方するのは、よくわかってないから例外ダメダメいってる連中なんだよな
適切に使われてる分には困るこたねーよ
適切に使われてる分には困るこたねーよ
>>107
それは戻り値にも言えることだろ
それは戻り値にも言えることだろ
だから例外の駄目なところは明示的に書けないところだけだって
戻り値と例外の違いなんてそこしかないぞ
戻り値と例外の違いなんてそこしかないぞ
例外で酷い使い方が横行するならgotoと同じで使用を自粛すべき
>>109
何を明示的に書くかが違うだけだろ。
例外は、エラーを無視するコードを明示的に書く。エラーの存在チェックは省略してもやってくれる。
戻り値エラーは、エラーの存在をチェックすることを明示的に書く。チェックを省略したらエラーが起きたことを無視する。
何を明示的に書くかが違うだけだろ。
例外は、エラーを無視するコードを明示的に書く。エラーの存在チェックは省略してもやってくれる。
戻り値エラーは、エラーの存在をチェックすることを明示的に書く。チェックを省略したらエラーが起きたことを無視する。
∧＿∧
（ ´∀｀）＜ ぬるぽ
（ ´∀｀）＜ ぬるぽ
>>105
全然気付かんかった。
そのメソッドの上位にエラーが伝わんないとか、
メソッド仕様が根本から変わってんじゃねぇか。
それは、まぁともかく。
メソッドが、自分が想定してるエラー処理パスにおいて、
自分のために例外投げるのって普通なん？
それもわりと意外だった。
自分の処理が中断した時に上位に通知するのが原則だと思ってんだが。
全然気付かんかった。
そのメソッドの上位にエラーが伝わんないとか、
メソッド仕様が根本から変わってんじゃねぇか。
それは、まぁともかく。
メソッドが、自分が想定してるエラー処理パスにおいて、
自分のために例外投げるのって普通なん？
それもわりと意外だった。
自分の処理が中断した時に上位に通知するのが原則だと思ってんだが。
>>110
gotoはreturnやbreakなんかで置き換え可能。
だから使わなくてプログラムは作れる。
よく言われることだけど、今では
エラー処理に関してはgotoを使っていいと言われているし、
実際LinuxのKernelのソースコードなんかも
エラー処理の部分でgotoはよく使われている。
なぜなら、C言語にはreturnやbreakのようにエラー処理を
効率的にやるために置き換える命令が存在しないから。
で、エラー処理をgotoを使わずに行える専用の命令として作られたのが
例外なんだよ。実際Javaなんかはgotoを本当に使わなくても作れるようになってる。
例外はgoto不要論が行き着いた先でもあるんだよ。
gotoはreturnやbreakなんかで置き換え可能。
だから使わなくてプログラムは作れる。
よく言われることだけど、今では
エラー処理に関してはgotoを使っていいと言われているし、
実際LinuxのKernelのソースコードなんかも
エラー処理の部分でgotoはよく使われている。
なぜなら、C言語にはreturnやbreakのようにエラー処理を
効率的にやるために置き換える命令が存在しないから。
で、エラー処理をgotoを使わずに行える専用の命令として作られたのが
例外なんだよ。実際Javaなんかはgotoを本当に使わなくても作れるようになってる。
例外はgoto不要論が行き着いた先でもあるんだよ。
gotoの代わりにしか見えんけど
>>116
gotoの何が悪いかを知っていれば、
gotoから悪い部分を取り除いたものが
例外ってわかるはずなんだが。
盲目的にgotoだから駄目だという時代は終わってるよ。
何故駄目かを考えないと。
gotoの何が悪いかを知っていれば、
gotoから悪い部分を取り除いたものが
例外ってわかるはずなんだが。
盲目的にgotoだから駄目だという時代は終わってるよ。
何故駄目かを考えないと。
error = checkXXX(checkee);
if (error) {msg = "error1"; break;}
error = checkYYY(checkee);
if (error) {msg = "error1"; break;}
：
return !error;
みたいなのみるともうちょっとマシなやり方あるだろって思っちゃうな
if (error) {msg = "error1"; break;}
error = checkYYY(checkee);
if (error) {msg = "error1"; break;}
：
return !error;
みたいなのみるともうちょっとマシなやり方あるだろって思っちゃうな
>>115
>>25はメッセージを表示したあと呼び出し元にfalseが返るんだけど
>>105はメッセージを表示したあと呼び出し元に例外が上がらない件について、
>>106がどう関係してるのか、良ければもう少し詳しく頼む。
>>25はメッセージを表示したあと呼び出し元にfalseが返るんだけど
>>105はメッセージを表示したあと呼び出し元に例外が上がらない件について、
>>106がどう関係してるのか、良ければもう少し詳しく頼む。
>>25のコードはエラーメッセージを出した後に
戻り値を返しているから根本的の間違いなんだよ。
あれをベースにしたら、どうやっても駄目なコードになるに決まってる。
その原因は>>25
じゃあ、>>25のコードをまともに書き換えようとこうなる。
bool func() {
if(!checkXXX()){
return false;
}
・
・ その他の処理
・
return true;
}
だが、このコードではエラーメッセージがなくなる。
じゃあエラーメッセージをどうやって出すか。
考えれば考えるほど、例外の素晴らしさに辿りつくはずなんだがね。
戻り値を返しているから根本的の間違いなんだよ。
あれをベースにしたら、どうやっても駄目なコードになるに決まってる。
その原因は>>25
じゃあ、>>25のコードをまともに書き換えようとこうなる。
bool func() {
if(!checkXXX()){
return false;
}
・
・ その他の処理
・
return true;
}
だが、このコードではエラーメッセージがなくなる。
じゃあエラーメッセージをどうやって出すか。
考えれば考えるほど、例外の素晴らしさに辿りつくはずなんだがね。
>>119
> >>25はメッセージを表示したあと呼び出し元にfalseが返るんだけど
その設計が大間違い。
メッセージを出すのはエラー情報を受け取った側が出すもので、
メッセージを先に出したらいけない。
ロジック部分にUIが混ざってる。
UI（メッセージボックス）はロジック部分が終わってから
つまり戻り値を受け取ってからするべきこと。
例外を理解してない人って、こういう設計感が欠けてるんだよな。
> >>25はメッセージを表示したあと呼び出し元にfalseが返るんだけど
その設計が大間違い。
メッセージを出すのはエラー情報を受け取った側が出すもので、
メッセージを先に出したらいけない。
ロジック部分にUIが混ざってる。
UI（メッセージボックス）はロジック部分が終わってから
つまり戻り値を受け取ってからするべきこと。
例外を理解してない人って、こういう設計感が欠けてるんだよな。
だれも「例外を使っていけない」っと言うわけじゃない。
例外でエラー処理をする奴はアホだと言っている。
>盲目的にgotoだから駄目だという時代は終わってるよ。
>何故駄目かを考えないと。
お前が終わっているだけだよ、気づけよ。
例外でエラー処理をする奴はアホだと言っている。
>盲目的にgotoだから駄目だという時代は終わってるよ。
>何故駄目かを考えないと。
お前が終わっているだけだよ、気づけよ。
例外でエラー処理をしなかったら
なんに使うんだよｗ
あ、答えなくていいよｗ
なんに使うんだよｗ
あ、答えなくていいよｗ
普通は
例外メッセージ ＝ 例外の型の名前
ってところか
サーバやOSからの応答文字列なんかをそのままフィールドに保存して渡したりはするけど
例外メッセージ ＝ 例外の型の名前
ってところか
サーバやOSからの応答文字列なんかをそのままフィールドに保存して渡したりはするけど
だから、昔のgotoの使い方にみえるってこと
switchのGOTOは使うけどな
あれは便利
あれは便利
>例外でエラー処理をしなかったら
>なんに使うんだよｗ
アホ丸出しだな、俺が>>14で書いた通り
>例外が起きたら、やることは２つ「リカバリーとリソース保護」だ。
なぜ例外でエラー処理をする馬鹿がこんなに多いのか？
>なんに使うんだよｗ
アホ丸出しだな、俺が>>14で書いた通り
>例外が起きたら、やることは２つ「リカバリーとリソース保護」だ。
なぜ例外でエラー処理をする馬鹿がこんなに多いのか？
じゃあエラー処理はどこで判断してやるんだっていう
>>120>>121
うーん、よくわかんね。
せめてこうじゃねぇの？
try {
try {
checkXXX();
} catch(Exception e) {
throw new MyXXXException(e);
}
} catch(MyXXXException e) {
MessageBox("XXXXXX");
printlog(e)
}
うーん、よくわかんね。
せめてこうじゃねぇの？
try {
try {
checkXXX();
} catch(Exception e) {
throw new MyXXXException(e);
}
} catch(MyXXXException e) {
MessageBox("XXXXXX");
printlog(e)
}
>>113
> 自分のために例外
そっちが楽なときはそうするかなー
真偽以外の結果が欲しい場合とか、いくつかのメソッドでの例外として
同じ復旧が必要な処理がいくつかある場合とかに、便利
自分の中だからフィールドとかで値渡してもいいけど
判定したりしないといけなくなる手間考えると、
複数の同類メソッド並べてtryで囲って、ってほうがめんどくさくない
例外newするのに困るほどパフォーマンス云々がシビアな環境でやるなら考慮もいるだろうけど
昨今じゃそんなの必要とするのは、組込みみたいな泥臭い業界でも減ってるし
投げるものも基本的には既存の例外が殆どだけど
業務例外的なものをExceptionクラスでやると、内部知らない人がぱっと見紛らわしくなったり
不具合も捕まえてしまう可能性もあるから、
プロジェクト内で使う汎用例外みたいなの用意してたりもすることも
> 自分のために例外
そっちが楽なときはそうするかなー
真偽以外の結果が欲しい場合とか、いくつかのメソッドでの例外として
同じ復旧が必要な処理がいくつかある場合とかに、便利
自分の中だからフィールドとかで値渡してもいいけど
判定したりしないといけなくなる手間考えると、
複数の同類メソッド並べてtryで囲って、ってほうがめんどくさくない
例外newするのに困るほどパフォーマンス云々がシビアな環境でやるなら考慮もいるだろうけど
昨今じゃそんなの必要とするのは、組込みみたいな泥臭い業界でも減ってるし
投げるものも基本的には既存の例外が殆どだけど
業務例外的なものをExceptionクラスでやると、内部知らない人がぱっと見紛らわしくなったり
不具合も捕まえてしまう可能性もあるから、
プロジェクト内で使う汎用例外みたいなの用意してたりもすることも
ごめん、知能障害でもあるんじゃないかってバカが混ざってるようにしか見えないｗｗｗ
(´･ω･`)あのあの
(´･ω･`)また用語の意識あわせから始めないといけないんじゃないの？
自分はエラー処理も復旧もだいたい同じ意味で使ってるけれど。
正常系に戻すための手順であって、具体的には代替処理か、ロールバック、リトライ。
calleeで正常系へと戻せなければ基本は再スロー。あとはcallerがどうにかするだろう的な。
あとは、正常系は本来の目的までのルート
異常系はメソッド内で片付かなかった問題を正常系に戻すまでのルート
代替処理(文字を数値に変換できなかった例外をうけて0を代入するとか)なりリトライなりを
行う部分で、そこで例外が片付けばそっから先は正常系
(´･ω･`)また用語の意識あわせから始めないといけないんじゃないの？
自分はエラー処理も復旧もだいたい同じ意味で使ってるけれど。
正常系に戻すための手順であって、具体的には代替処理か、ロールバック、リトライ。
calleeで正常系へと戻せなければ基本は再スロー。あとはcallerがどうにかするだろう的な。
あとは、正常系は本来の目的までのルート
異常系はメソッド内で片付かなかった問題を正常系に戻すまでのルート
代替処理(文字を数値に変換できなかった例外をうけて0を代入するとか)なりリトライなりを
行う部分で、そこで例外が片付けばそっから先は正常系
今日初めて見たけど
＞ (´･ω･`)あのあの
＞ (´･ω･`)また用語の意識あわせから始めないといけないんじゃないの？
2chの場合人がすぐ入れ替わるから、あ・た・り・ま・え
＞ (´･ω･`)あのあの
＞ (´･ω･`)また用語の意識あわせから始めないといけないんじゃないの？
2chの場合人がすぐ入れ替わるから、あ・た・り・ま・え
そんな言い方ってない
例外は大規模向きで
戻り値エラーは小規模用だよな。
言語機能もそうだけど、
ここで話している人のやりとりを見ると、
戻り値エラーの人は小さな部分しか考えてなくて
パッチ当てる感覚で行き当たりばったりの対応、
自分一人でやる。俺はできるからいいんだみたいな話し方で、
例外の人はシステム全体のことを話してる。
設計とかパターンとかフレームワークとかスキルも知識も
違う多人数開発でどれだけ統一させて作るかってそんな感じ
戻り値エラーは小規模用だよな。
言語機能もそうだけど、
ここで話している人のやりとりを見ると、
戻り値エラーの人は小さな部分しか考えてなくて
パッチ当てる感覚で行き当たりばったりの対応、
自分一人でやる。俺はできるからいいんだみたいな話し方で、
例外の人はシステム全体のことを話してる。
設計とかパターンとかフレームワークとかスキルも知識も
違う多人数開発でどれだけ統一させて作るかってそんな感じ
始めて見たスレで一言目がスレ違い
ついていけないなら無理にレスしなくても大丈夫ですよー＾＾
ついていけないなら無理にレスしなくても大丈夫ですよー＾＾
>>136
自分の処理内なら戻り値の型がどうのとか気にしなくていいしなー
例外の使い方がよくわかってない人は、基本的に同じような処理をベースに
コピペ切り貼りして、なんも知らないとちょっと分かり辛い例外の使いまわし方とか
良く理解しないまま真似て事なきを得ちゃってるから、ちょっと難しくなると
わかんねーようぜぇってなってしまうんだと思う
特に、仕事として仕事でしかコーディングしない人、最近の流れを知らない人みたいな
興味を持たない人だったりするとそんな感じ
難しく考えないで、戻り値が複数ある、程度の認識でも充分だと思うんだけどね
通常の戻り値は正常な値だけで、異常の場合は複数の戻ってくるパターンがある、ってだけ
try {
正常な戻り値 = func();
} catch (Type1Exception 異常な戻り値1) {
//リカバリー ロールバック リトライ 再スローなど
} catch (Type2Exception 異常な戻り値2) {
//リカバリー ロールバック リトライ 再スローなど
}
自分の処理内なら戻り値の型がどうのとか気にしなくていいしなー
例外の使い方がよくわかってない人は、基本的に同じような処理をベースに
コピペ切り貼りして、なんも知らないとちょっと分かり辛い例外の使いまわし方とか
良く理解しないまま真似て事なきを得ちゃってるから、ちょっと難しくなると
わかんねーようぜぇってなってしまうんだと思う
特に、仕事として仕事でしかコーディングしない人、最近の流れを知らない人みたいな
興味を持たない人だったりするとそんな感じ
難しく考えないで、戻り値が複数ある、程度の認識でも充分だと思うんだけどね
通常の戻り値は正常な値だけで、異常の場合は複数の戻ってくるパターンがある、ってだけ
try {
正常な戻り値 = func();
} catch (Type1Exception 異常な戻り値1) {
//リカバリー ロールバック リトライ 再スローなど
} catch (Type2Exception 異常な戻り値2) {
//リカバリー ロールバック リトライ 再スローなど
}
>>138
よう蛙。そんなに自分の井戸が自慢か？
よう蛙。そんなに自分の井戸が自慢か？
catchの中でリトライするか？
例えば10回までリトライする場合、try, catchのネストが10段になるじゃん
例えば10回までリトライする場合、try, catchのネストが10段になるじゃん
どうやって、catchの中でリトライするんだ？
ネスト的に無理だろｗ
ネスト的に無理だろｗ
例外が出たら出なくなるまでリトライする場合ってどうするの？こんな感じ？
while(bool retry=true) {
try {
例外を出すかもしれないメソッド();
retry = false;
} catch(とある例外 ex) {
retry = true;
}
}
while(bool retry=true) {
try {
例外を出すかもしれないメソッド();
retry = false;
} catch(とある例外 ex) {
retry = true;
}
}
>>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;
}
}
}
}
普通に考えたらこう
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;
}
}
}
}
ファイルアクセスや通信なんて、テメェのスレッドでやらせるか？
>>144
while(1) {
try {
例外を出すかもしれないメソッド();
break;
} catch(とある例外 ex) {
}
}
いつかは例外が発生しなくなると
わかってる前提じゃないと使いたくないけどね。
while(1) {
try {
例外を出すかもしれないメソッド();
break;
} catch(とある例外 ex) {
}
}
いつかは例外が発生しなくなると
わかってる前提じゃないと使いたくないけどね。
>>142
catch句の中でリトライするって意味で使ってたわけじゃないんだけど、
こりゃ使い方よくないわな。スマソ
物凄く簡単に書くなら、こういう感じのイメージ
int i = 0;
while (i++ < 10) {
try {
retryFunc();
} catch (MyException ex) {
continue;
}
：
}
自分の中だけでリトライできない場合で、リトライできる場所がキャッチしてやればOK
何回リトライ、っていうか無限ループしてるような処理で考えてもらったほうが分かりやすいかも？
catch句の中でリトライするって意味で使ってたわけじゃないんだけど、
こりゃ使い方よくないわな。スマソ
物凄く簡単に書くなら、こういう感じのイメージ
int i = 0;
while (i++ < 10) {
try {
retryFunc();
} catch (MyException ex) {
continue;
}
：
}
自分の中だけでリトライできない場合で、リトライできる場所がキャッチしてやればOK
何回リトライ、っていうか無限ループしてるような処理で考えてもらったほうが分かりやすいかも？
例外分かってないのってコボラーじゃね？
失敗したら即リトライ再開とかｗ
最近発表されたばかりの論文だが、例外使用時の方がシステムの不具合が多くなるそうだ。
学会では例外禁止がすでに常識
学会では例外禁止がすでに常識
>>153
そうか、学会か。
そうか、学会か。
ユーザー入力値をチェックして間違えてたら入力値不正例外を投げる
入力受け付ける処理は、入力値不正例外をキャッチして、
もっかい入力させなおす、とかそういう感じなのを想像すると分かりやすいかも？
入力チェック処理の中のどこでNGになった場合でも、
チェック処理は入力不正例外を作って投げてやればいいだけなので
自分のなかでどんだけプライベートメソッド持ってたりしても、
どこからでも即異常系のreturnができる、みたいな使い方できるのがメリット
例外処理するほうも共通のやり方で出来るように例外をきちんと設計してあれば、
チェック処理増やしても変更が必要ないし、チェック処理自体をモジュールに出来るから
追加削除がしやすくなるのん
入力受け付ける処理は、入力値不正例外をキャッチして、
もっかい入力させなおす、とかそういう感じなのを想像すると分かりやすいかも？
入力チェック処理の中のどこでNGになった場合でも、
チェック処理は入力不正例外を作って投げてやればいいだけなので
自分のなかでどんだけプライベートメソッド持ってたりしても、
どこからでも即異常系のreturnができる、みたいな使い方できるのがメリット
例外処理するほうも共通のやり方で出来るように例外をきちんと設計してあれば、
チェック処理増やしても変更が必要ないし、チェック処理自体をモジュールに出来るから
追加削除がしやすくなるのん
ソースのない多数の意見ｗ
学会を馬鹿にするな。
俺は学会員だぞ。
俺は学会員だぞ。
渡されたファイル名が空文字列だったので例外投げました（ｷﾘｯ
>>158
は？ すぐにリトライしたら駄目なら、
すぐにリトライしないようにすればいいじゃん。
それだけだよね？
他に迷惑？なにそれ？
何が迷惑を書けてることになるって？
俺、すぐにリトライしない方法の
具体的な実装の話してないんけど、
何に突っ込み入れてるの？
は？ すぐにリトライしたら駄目なら、
すぐにリトライしないようにすればいいじゃん。
それだけだよね？
他に迷惑？なにそれ？
何が迷惑を書けてることになるって？
俺、すぐにリトライしない方法の
具体的な実装の話してないんけど、
何に突っ込み入れてるの？
>>160
どうしてほしいのさｗ
どうしてほしいのさｗ
ブラックボックスというのは、
中でどんな処理を行っているかわからないという意味で、
中から外に情報を教えないという意味じゃないと思うんだけどなー（苦笑）
中でどんな処理を行っているかわからないという意味で、
中から外に情報を教えないという意味じゃないと思うんだけどなー（苦笑）
起きてからの事ばっかり心配して、起こさない事には脳ミソ使ってない人が、
例外を異常に崇拝してる。
屁理屈付きのスパゲッティプログラムという印象しかない。
例外を異常に崇拝してる。
屁理屈付きのスパゲッティプログラムという印象しかない。
例外に文句付けてるやつって
どうもツメが甘いよな。
色々とおかしいところを指摘されまくる
気分ってどんなだろう。
どうもツメが甘いよな。
色々とおかしいところを指摘されまくる
気分ってどんなだろう。
＞起こさない事には脳みそ使ってない
不具合は起こす起こさないじゃなくて、起きるもの。
お前は今まで一度でも不具合がないシステムを構築したことがあるのか？ まともな規模で
ねーだろ
不具合は起こす起こさないじゃなくて、起きるもの。
お前は今まで一度でも不具合がないシステムを構築したことがあるのか？ まともな規模で
ねーだろ
例外は崇拝するものじゃなくて常識だよ。
ほとんどの言語の標準ライブラリで
使われてるものなんだから、いやでも使って作る物。
それを使わないやつは馬鹿か仕方ない理由がある場合だけ。
ほとんどの言語の標準ライブラリで
使われてるものなんだから、いやでも使って作る物。
それを使わないやつは馬鹿か仕方ない理由がある場合だけ。
>中から外に情報を教えないという意味じゃないと思うんだけどなー（苦笑）
誰もそんな事指摘してないし。 自分に都合のいい様に相手の話を
ねじ曲げてるだけでしょ。
日本語もロクに理解出来ないくせに、人工言語が理解出来てるとは
思えないね。
誰もそんな事指摘してないし。 自分に都合のいい様に相手の話を
ねじ曲げてるだけでしょ。
日本語もロクに理解出来ないくせに、人工言語が理解出来てるとは
思えないね。
コイツ、言葉尻ばっかり捉えてるな。
>>158
いや、痛いところっていうかただの揚げ足取りだろｗ
いや、痛いところっていうかただの揚げ足取りだろｗ
ファイルアクセスさせる処理が失敗したら、その処理させる為に与えた
情報か環境のどちらかもしくは両方に問題があった事くらい、例外投げ
返されなくても分かるだろ普通。
じゃあせめて、与える情報の正当性くらい検証してからアクセスさせて
あげようかって考えるのが、まっとうな人間の考え方。
情報か環境のどちらかもしくは両方に問題があった事くらい、例外投げ
返されなくても分かるだろ普通。
じゃあせめて、与える情報の正当性くらい検証してからアクセスさせて
あげようかって考えるのが、まっとうな人間の考え方。
>>149
基本は1機能1メソッド、って考えるといいよ
例えば、ファイル1の文字列をファイル2の末尾に追加ーってサービスがあるとしたら
-ファイルを開くメソッド
-中身コピーするメソッド
-ファイルを閉じるメソッド
コピーメソッドから呼ばれるメソッドで
-ファイルから文字を取り出すメソッド
-ファイル末尾へ文字を書き出すメソッド
完結にその機能を表せる名前が付けれる単位で処理を分けていくといいよ
命名にも困りにくいし、メソッド内で何やってるかが名前から予想つくし
>>160
ファイル名事前にチェックすれば例外は発生しない！
検査例外の呪いは知らん！！
基本は1機能1メソッド、って考えるといいよ
例えば、ファイル1の文字列をファイル2の末尾に追加ーってサービスがあるとしたら
-ファイルを開くメソッド
-中身コピーするメソッド
-ファイルを閉じるメソッド
コピーメソッドから呼ばれるメソッドで
-ファイルから文字を取り出すメソッド
-ファイル末尾へ文字を書き出すメソッド
完結にその機能を表せる名前が付けれる単位で処理を分けていくといいよ
命名にも困りにくいし、メソッド内で何やってるかが名前から予想つくし
>>160
ファイル名事前にチェックすれば例外は発生しない！
検査例外の呪いは知らん！！
> じゃあせめて、与える情報の正当性くらい検証してからアクセスさせて
> あげようかって考えるのが、まっとうな人間の考え方。
その与える情報が正当でなかった場合に
返すのが例外ですよ。
> あげようかって考えるのが、まっとうな人間の考え方。
その与える情報が正当でなかった場合に
返すのが例外ですよ。
>>175
ﾊﾞｧｧｧｧｧｧｧｧｧｧｧｧｧｶ
ﾊﾞｧｧｧｧｧｧｧｧｧｧｧｧｧｶ
>与える情報が正当じゃなかったらどうすんの？ねぇねぇｗ
その処理呼び出さなければいいのでは？
オマエは、殴り書きして判別不可能な手書き文字で手紙とか書いて、
分からんかったら聞きに来いとか言ってしまえる欠陥人間なんだろうな。
その処理呼び出さなければいいのでは？
オマエは、殴り書きして判別不可能な手書き文字で手紙とか書いて、
分からんかったら聞きに来いとか言ってしまえる欠陥人間なんだろうな。
ま、自前にチェックしてから
ファイルアクセスすれば、例外なんか起きないというのは
初心者がよくやる初歩的な間違いなんだけどな。
まっとうではない、初心者だ。
なぜなら、チェックしてからアクセスするまでの
ごく僅かな時間で、アクセス不可になる事態が起こりえるから。
そこまで考慮できないんで初心者。
ファイルアクセスすれば、例外なんか起きないというのは
初心者がよくやる初歩的な間違いなんだけどな。
まっとうではない、初心者だ。
なぜなら、チェックしてからアクセスするまでの
ごく僅かな時間で、アクセス不可になる事態が起こりえるから。
そこまで考慮できないんで初心者。
>>164
そのメソッドで片付かない場合が例外
処理分けず、多機能なメソッドならそのあたりもまとめて考慮できるけど、
巨大なブロックを作ると、UTや修正の影響範囲がでかくなりすぎるだけ
検査例外の呪いで、事前にtester通してるのに例外を処理するよう書かないといけない、
なんて問題もJavaだとあるけど、そういう場合は事前チェックをサボればいいと考えてもいいっしょ
例外をnewすることですら躊躇しないといけない環境だってんなら、しょうがないけど
それなら起こりえない例外をキャッチしといて、コメントで発生しないので処理しないとでも残してあげるのがベター
>>168
脱線すんなってｗ
すぐ本題から反れてるから馬鹿にされるんでしょ
そのメソッドで片付かない場合が例外
処理分けず、多機能なメソッドならそのあたりもまとめて考慮できるけど、
巨大なブロックを作ると、UTや修正の影響範囲がでかくなりすぎるだけ
検査例外の呪いで、事前にtester通してるのに例外を処理するよう書かないといけない、
なんて問題もJavaだとあるけど、そういう場合は事前チェックをサボればいいと考えてもいいっしょ
例外をnewすることですら躊躇しないといけない環境だってんなら、しょうがないけど
それなら起こりえない例外をキャッチしといて、コメントで発生しないので処理しないとでも残してあげるのがベター
>>168
脱線すんなってｗ
すぐ本題から反れてるから馬鹿にされるんでしょ
レアケースにかこつけて、自分のゆるい設計思想を正当化してみました（ｷﾘｯ
実際にやらせてみたら失敗しましたって事は、あるかも知れんな。
でも俺、失敗の原因として、そういう可能性についても言及してるし。
都合の悪い事を無視するのは、オマエの一番悪いところだ。
実際にやらせてみたら失敗しましたって事は、あるかも知れんな。
でも俺、失敗の原因として、そういう可能性についても言及してるし。
都合の悪い事を無視するのは、オマエの一番悪いところだ。
>>178
くだらん例えは見るつもりはないんでｗ
ファイルアクセスしなかったとしても、
ファイルアクセスしなかったという事態を
呼び出し元に返さないといかんだろ。
その与えられた情報が正当ではなかったため
ファイルアクセスしませんでしたという情報を
例外で返すんだよ。
くだらん例えは見るつもりはないんでｗ
ファイルアクセスしなかったとしても、
ファイルアクセスしなかったという事態を
呼び出し元に返さないといかんだろ。
その与えられた情報が正当ではなかったため
ファイルアクセスしませんでしたという情報を
例外で返すんだよ。
>>172
拡大解釈して、「一回失敗してるのに何もせずにリトライするだなんてありえない！」
って意味何じゃないのかなーって読み取った
でもそれ仕様な話であって、サンプルコードとかに対していう事でもないよね
(´･ω･`)レスする価値もないと思ったので、とりあえず無視しました
拡大解釈して、「一回失敗してるのに何もせずにリトライするだなんてありえない！」
って意味何じゃないのかなーって読み取った
でもそれ仕様な話であって、サンプルコードとかに対していう事でもないよね
(´･ω･`)レスする価値もないと思ったので、とりあえず無視しました
>くだらん例えは見るつもりはないんでｗ
思いっきり反応してるくせにｗ
思いっきり反応してるくせにｗ
>>185
そこ、重要だったのか？ お前にとっては。
そこ、重要だったのか？ お前にとっては。
関数の中でメッセージを表示してから
戻り値を返すという糞発想。
くそなのは同意だが、めっさよく見る。
どうしたらいいんだよ
戻り値を返すという糞発想。
くそなのは同意だが、めっさよく見る。
どうしたらいいんだよ
(´･ω･`)あのあの
(´･ω･`)見えない敵と戦うのはやめてください
(´･ω･`)見えない敵と戦うのはやめてください
>>187
プログラムの設計を
ロジック部分とUI部分に分ける。
詳しくはMVCとか調べてくれということにして、
UI部分から、ユーザーのアクションで処理（ロジック）を開始して、
処理した結果をUI部分で表示する。
こうすることでロジックとUIが分離され、
UIを入れ替えて、たとえばCUIコマンドを作ったり、
ユニットテストを行えるようになる。
ロジック部分からは処理結果（例外を含む）を受け取り、
そしてUI部分で処理結果を表示する。
こういうのがいまどきの良い設計。
プログラムの設計を
ロジック部分とUI部分に分ける。
詳しくはMVCとか調べてくれということにして、
UI部分から、ユーザーのアクションで処理（ロジック）を開始して、
処理した結果をUI部分で表示する。
こうすることでロジックとUIが分離され、
UIを入れ替えて、たとえばCUIコマンドを作ったり、
ユニットテストを行えるようになる。
ロジック部分からは処理結果（例外を含む）を受け取り、
そしてUI部分で処理結果を表示する。
こういうのがいまどきの良い設計。
>その与えられた情報が正当ではなかったため
>ファイルアクセスしませんでしたという情報を
>例外で返すんだよ。
そんな事するくらいなら、その場でメッセージボックス出せばよろしい。
出せないなら、チラシの裏にでも記録しておけばいい。
呼び出し元は、本来やらせたい事の成否だけが分かればいい。
正常系は、そういう流れで作られている。
そしてそいつにとっての異常系は、そんな細かい事柄について処理する
ために実装されてはいけない。
オマエが言ってる事は、僻地の役場の便所が詰まった事について、監督
官庁の大臣にあれこれ対処させようとするようなもの。
>ファイルアクセスしませんでしたという情報を
>例外で返すんだよ。
そんな事するくらいなら、その場でメッセージボックス出せばよろしい。
出せないなら、チラシの裏にでも記録しておけばいい。
呼び出し元は、本来やらせたい事の成否だけが分かればいい。
正常系は、そういう流れで作られている。
そしてそいつにとっての異常系は、そんな細かい事柄について処理する
ために実装されてはいけない。
オマエが言ってる事は、僻地の役場の便所が詰まった事について、監督
官庁の大臣にあれこれ対処させようとするようなもの。
↑
ほーらな。想定通り>>25のクソコードにつながったｗ
ほーらな。想定通り>>25のクソコードにつながったｗ
やっぱり例外を分かってない人ってのは
ロジックとUIを分離するって考えすら無いよなぁ。
その場でメッセージボックスを出すとか
まともな人ならやらないことだよ。
ロジックとUIを分離するって考えすら無いよなぁ。
その場でメッセージボックスを出すとか
まともな人ならやらないことだよ。
>>195
んで対策は？
んで対策は？
とりあえずよくわからないけど、食い扶持になるから、っていう職業マの数多いしな
ぶっちゃけこのあたりは興味持ってくれる奴じゃないと、どうしようもないと思う
うちの仕事場、今のプロジェクト用のそれなりに噛み砕いたドキュメントとか用意してあるけど
全く守ってないコーディングしてるやつが腐るほどいるしな
ぶっちゃけこのあたりは興味持ってくれる奴じゃないと、どうしようもないと思う
うちの仕事場、今のプロジェクト用のそれなりに噛み砕いたドキュメントとか用意してあるけど
全く守ってないコーディングしてるやつが腐るほどいるしな
例外使ってる時はいつもフルボッキです（ｷﾘｯ
>>197
コミュニケーションよりも
技術力を付けることが大事。
という考えを普及させること
あたりまえのことなのに、たとえば
スポーツ選手に技術力より英語力のほうが大事と
真面目に言っているバカが多いのがこの業界。
ま、言ってるやつは技術ないんだがｗ
一見、世界で活躍するためには英語力が必要だから
正しいことを言っているように見えるが、
「そもそもとして技術がなけりゃどうしようもないだろ」ってことを
分かってない。
コミュニケーションよりも
技術力を付けることが大事。
という考えを普及させること
あたりまえのことなのに、たとえば
スポーツ選手に技術力より英語力のほうが大事と
真面目に言っているバカが多いのがこの業界。
ま、言ってるやつは技術ないんだがｗ
一見、世界で活躍するためには英語力が必要だから
正しいことを言っているように見えるが、
「そもそもとして技術がなけりゃどうしようもないだろ」ってことを
分かってない。
>コミュニケーションよりも
>技術力を付けることが大事。
>という考えを普及させること
欠陥人間の本音ｋｔｋｒ
>技術力を付けることが大事。
>という考えを普及させること
欠陥人間の本音ｋｔｋｒ
っていうか例外を好みだけで否定してる人ばっかだしな
わけがわからないよ
わけがわからないよ
昔
try {
//xxxx;
} catch {
throw new Exception("");
}
ってのを見たときにはマジで例外禁止にしようかと思った。
そのあと冷静に考えて、そのバカ首にした方がいいんじゃねーかと思い
さらに冷静に考えて、首にする権限なんてないって気づいた。
俺に組織の改革なんて無理なんだな
try {
//xxxx;
} catch {
throw new Exception("");
}
ってのを見たときにはマジで例外禁止にしようかと思った。
そのあと冷静に考えて、そのバカ首にした方がいいんじゃねーかと思い
さらに冷静に考えて、首にする権限なんてないって気づいた。
俺に組織の改革なんて無理なんだな
>>200
常識だよな、それ
常識だよな、それ
とうとう自演まで始めましたよ？
>>206
そこでやるべきは、例外を禁止するのではなく、
例外の正しい使い方を教えることだ。
標準ライブラリが例外はくのに、
例外を禁止することなんて不可能だろう？
正しい使い方を教えないと、
いつまでもそういうコード見ることになるぞ。
そこでやるべきは、例外を禁止するのではなく、
例外の正しい使い方を教えることだ。
標準ライブラリが例外はくのに、
例外を禁止することなんて不可能だろう？
正しい使い方を教えないと、
いつまでもそういうコード見ることになるぞ。
>>197
根本的には、しょっぱい奴をクビに出来る社会にならないと解決しない。
根本的には、しょっぱい奴をクビに出来る社会にならないと解決しない。
俺以外はみんな死んじゃえよ（ｷﾘｯ
なんだ、ただの厨二病か
なんだ、ただの厨二病か
>>213
それはつまり今が改革の時ってことだよ！！！
それはつまり今が改革の時ってことだよ！！！
>俺も昔は例外分かってない時代があったから
コイツの器の程度が知れる発言ですな ┐(´д｀)┌ﾔﾚﾔﾚ
コイツの器の程度が知れる発言ですな ┐(´д｀)┌ﾔﾚﾔﾚ
（くやしい…ﾋﾞｸﾝﾋﾞｸﾝ）
（荒らしてやる…荒らしてやる…）
（荒らしてやる…荒らしてやる…）
今日も相変わらず精度のいいブーメラン投げてる奴がいるのなｗ
名無しでぐだぐだやってるあたりuyより酷いｗ
名無しでぐだぐだやってるあたりuyより酷いｗ
結局、反りの合わない上司の悪口言うためのスレだったのね
よくあるロールバック処理のサンプルコードを例外で書いた。
・・・が、このサイトでは動かなかった。（Visual C++では動いた）
http://ideone.com/2JeE1
しかし、一体このコードを書くのに、俺はどれだけの時間を無駄にしたんだろうｗ
・・・が、このサイトでは動かなかった。（Visual C++では動いた）
http://ideone.com/2JeE1
しかし、一体このコードを書くのに、俺はどれだけの時間を無駄にしたんだろうｗ
昨日みたダメコード
try {
：
} catch (Exception e) {
throw e;
}
おまえはいったい、なにがしたいんだ…
try {
：
} catch (Exception e) {
throw e;
}
おまえはいったい、なにがしたいんだ…
つまり何が言いたいんですか？
計算途中はテンポラリを使って、最後までうまく行った時だけ、それを
本ちゃんの奴にコピーすればいいんじゃないんですか？
それだと、どんな致命的欠陥があるんですか？
計算途中はテンポラリを使って、最後までうまく行った時だけ、それを
本ちゃんの奴にコピーすればいいんじゃないんですか？
それだと、どんな致命的欠陥があるんですか？
/**
* Hogeを取得します。
* @return
* @throws Exception 例外が発生した場合 ←
public Hoge getHoge() throws Exception {
：
ｲﾗｯ
型もあれだが説明も酷い
* Hogeを取得します。
* @return
* @throws Exception 例外が発生した場合 ←
public Hoge getHoge() throws Exception {
：
ｲﾗｯ
型もあれだが説明も酷い
Oh、1行消してしまった。分かるだろうけど
ロールバック処理の途中で例外が起きないことは、宇宙の法則で決まってるのだろうか・・・
>>223
そういうのばっかの環境にいると、例外ばくはつしろってなる気持ちも分からんでもないなｗ
そういうのばっかの環境にいると、例外ばくはつしろってなる気持ちも分からんでもないなｗ
>>219
事前にオブジェクトのcloneを作って保持して、例外がおきたら書き戻す、それだけの話じゃないのん？
サンプルコードを起こした意図がイマイチわからないかもー
あとCプラ触ったことないんだけど
O backup = obj;
こういうのって参照のコピーではなくてクローンになるん？
参照だったら、logicAが終わったタイミングでdata[0]とdata[1]入れ替わっちゃったりしない？
それとそれと、サンプルだからそれでもいいとは思うけれど、
さっきちょいちょい話題にあがってた、処理層を意識するばやい、
アウトプットはそれはそれでまとめたほうがいいんじゃないのん
復旧と出力をまとめると、キャッチ句が多機能になっちゃうし
っていうか、中で弄ってこけたら外で書き戻す、ってよりは
処理するメソッドの成功時だけ参照を更新してやるほうがいいと思うの
事前にオブジェクトのcloneを作って保持して、例外がおきたら書き戻す、それだけの話じゃないのん？
サンプルコードを起こした意図がイマイチわからないかもー
あとCプラ触ったことないんだけど
O backup = obj;
こういうのって参照のコピーではなくてクローンになるん？
参照だったら、logicAが終わったタイミングでdata[0]とdata[1]入れ替わっちゃったりしない？
それとそれと、サンプルだからそれでもいいとは思うけれど、
さっきちょいちょい話題にあがってた、処理層を意識するばやい、
アウトプットはそれはそれでまとめたほうがいいんじゃないのん
復旧と出力をまとめると、キャッチ句が多機能になっちゃうし
っていうか、中で弄ってこけたら外で書き戻す、ってよりは
処理するメソッドの成功時だけ参照を更新してやるほうがいいと思うの
catch の部分が関数の途中にあるのが気持ち悪い。
これ、実用のコードだと、try - catch のカタマリが、関数の中の至る所に出てくるんだろ？
正常系考える時はそこを読み飛ばせとか、ちょっとムリがあるんじゃないの？
これ、実用のコードだと、try - catch のカタマリが、関数の中の至る所に出てくるんだろ？
正常系考える時はそこを読み飛ばせとか、ちょっとムリがあるんじゃないの？
コピーコンストラクタがあるじゃまいか
>>231
なるほそ。理解したthx
なるほそ。理解したthx
>>230
机上デバッグとか冗長メソッドとかが大好きな人なん？
っていうかtry-catch句なんて構文の一つだろ
理解できてないから気になっちゃうのかもしれんけど
つか、他人が書いたソースを読むのは勉強のときで
俺なら他人が作った機能を呼ぶならドキュメントを見るけどなｗ
机上デバッグとか冗長メソッドとかが大好きな人なん？
っていうかtry-catch句なんて構文の一つだろ
理解できてないから気になっちゃうのかもしれんけど
つか、他人が書いたソースを読むのは勉強のときで
俺なら他人が作った機能を呼ぶならドキュメントを見るけどなｗ
ああそうか、正常終了したときにデータ更新すればいいのか。
ん？でも処理をリトライする時に、結局データをコピーするよな...
それだと、変数の意味が違ってくるだけじゃないか？
ん？でも処理をリトライする時に、結局データをコピーするよな...
それだと、変数の意味が違ってくるだけじゃないか？
Javaしか知らないのが混じってるから話が。
検査例外なんかほかにねーってよ。
検査例外なんかほかにねーってよ。
>Javaしか知らないのが混じってるから話が。
オマエは、しょーもない事で煽るなよ。
オマエは、しょーもない事で煽るなよ。
リトライするのは上位じゃないのかよｗ
とまあ、現実でもコードレビューでこんなふうに周りから寄ってたかって
厳しいツッコミ入れられて涙目になってるんだろうなｗ
厳しいツッコミ入れられて涙目になってるんだろうなｗ
戻り値例外派がひどい。
戻り値で例外を判断するのは構わんが、
例外の内容を戻り値に入れるなよ。
Nullないし-1だけでいい。
何でCがerrno+perror使ってたり、
windowsがGetLastError使ってるか
理解してねぇだろ。
戻り値で例外を判断するのは構わんが、
例外の内容を戻り値に入れるなよ。
Nullないし-1だけでいい。
何でCがerrno+perror使ってたり、
windowsがGetLastError使ってるか
理解してねぇだろ。
>>234
全部台無しってのは具体的に何がどう台無しになったんだ？
何時もそうだけど、批判するために批判するのそろそろやめたほうがいいぞ
あと何のドキュメントを上げろって言ってんだ？
実際に使うだけなら、コード見る必要なんてないっていう話なんだけど、難しかったかな＾＾；
>>235
あのサンプルでの話しであれば、ループのなかで値コピーして処理して
結果が問題なければ元のやつに書き戻せばいいんでね
全部台無しってのは具体的に何がどう台無しになったんだ？
何時もそうだけど、批判するために批判するのそろそろやめたほうがいいぞ
あと何のドキュメントを上げろって言ってんだ？
実際に使うだけなら、コード見る必要なんてないっていう話なんだけど、難しかったかな＾＾；
>>235
あのサンプルでの話しであれば、ループのなかで値コピーして処理して
結果が問題なければ元のやつに書き戻せばいいんでね
>>何でCがerrno+perror使ってたり、
>windowsがGetLastError使ってるか
>理解してねぇだろ。
あ、GetLastError はアリなんだ。 そういう仕組実装したらどうかと提案
しようと思ってたけど、ムダに煽られると思って控えてたんだが。
だって、例外投げる必要なくなるもんｗ
>windowsがGetLastError使ってるか
>理解してねぇだろ。
あ、GetLastError はアリなんだ。 そういう仕組実装したらどうかと提案
しようと思ってたけど、ムダに煽られると思って控えてたんだが。
だって、例外投げる必要なくなるもんｗ
そこでGoですよ、Cの本家が作った。
戻り値が複数あるからエラーは別に返せるしdeferで後始末もする。
RTEの脱出はpanicとrecoverで大丈夫。
StringもMapも組込型な上GCもアリでダックタイプ、
継承はないけどインターフェースはあり。
要は使えるモノは親兄弟関係なく使え。
が強い型付けの静的言語。ヤんなきゃわからんことはない。
でもtry-catchはありません。例外はない、と言っていいのかな。
X64(86)とARMバイナリはおｋ。
いかがっすか〜
戻り値が複数あるからエラーは別に返せるしdeferで後始末もする。
RTEの脱出はpanicとrecoverで大丈夫。
StringもMapも組込型な上GCもアリでダックタイプ、
継承はないけどインターフェースはあり。
要は使えるモノは親兄弟関係なく使え。
が強い型付けの静的言語。ヤんなきゃわからんことはない。
でもtry-catchはありません。例外はない、と言っていいのかな。
X64(86)とARMバイナリはおｋ。
いかがっすか〜
あちこちに依存してしまうグローバルな値は使いたくねーけどなｗ
結論 ： 例外は不要
>>241
んー、結局正常処理の最後に、backupへのコピーを付けるだけになる気がするんだ。
んー、結局正常処理の最後に、backupへのコピーを付けるだけになる気がするんだ。
>>248
後者
いやね、例外じゃない場合めんどくさいほうが違いが分かるかなと思っただけ
その程度の差だしどっちでもいいんだけど
メリットを主張するならそっちのほうが比較になっていいんじゃねーかなーって程度の話ね
後者
いやね、例外じゃない場合めんどくさいほうが違いが分かるかなと思っただけ
その程度の差だしどっちでもいいんだけど
メリットを主張するならそっちのほうが比較になっていいんじゃねーかなーって程度の話ね
>>249
そうか、じゃ考えとく。
そうか、じゃ考えとく。
>>241
オマエの残念な人格についての話だと思うんだけど、難しかったかな＾＾
オマエの残念な人格についての話だと思うんだけど、難しかったかな＾＾
>>250
それも、前に中華に作らせたC#でやってる奴いたわｗ
幸いこっちのはJavaだったからその手の心配はなかったんだけど
ほんとにそのまんまの書き方だったんだよね
なんもしねーのにcatchしちゃったのは、コピペした結果なのかなぁとは思うけれど
それも、前に中華に作らせたC#でやってる奴いたわｗ
幸いこっちのはJavaだったからその手の心配はなかったんだけど
ほんとにそのまんまの書き方だったんだよね
なんもしねーのにcatchしちゃったのは、コピペした結果なのかなぁとは思うけれど
必要に応じて対処出来るように、とっかかりを用意したのでは？
チェック例外でコンパイルひっかかるからとりあえず全部上に投げただけじゃないのか？
握りつぶさないだけマシ…じゃないよなｗ
握りつぶさないだけマシ…じゃないよなｗ
>>253
あとで何かするつもりだったけど忘れてしまった
あとで何かするつもりだったけど忘れてしまった
>>255
チェック例外じゃなかったら、無くても良いコードだろうし、別にいいんじゃね。
チェック例外じゃなかったら、無くても良いコードだろうし、別にいいんじゃね。
例外でエラー処理を書く利点として
エラー処理を一箇所で宣言的に書けるという利点がある。
例外処理以外は正常系だけを書けば良いから可視化は良くなるかも．．．
>>220
どんなシステムか分からないが、例えばEXEとDLLの関係で
DLLの例外をEXEに処理させたい場合に、まずDLLで例外をオブジェクトにマッピングして
EXEに投げると正しく捕まえてくれるとかもあるが．．．これだけだと分からん。
意味が無いと思うことでも、自分が知識が無いだけの場合も多いからな。
まっ本当に意味がないだけかも知れないが。
エラー処理を一箇所で宣言的に書けるという利点がある。
例外処理以外は正常系だけを書けば良いから可視化は良くなるかも．．．
>>220
どんなシステムか分からないが、例えばEXEとDLLの関係で
DLLの例外をEXEに処理させたい場合に、まずDLLで例外をオブジェクトにマッピングして
EXEに投げると正しく捕まえてくれるとかもあるが．．．これだけだと分からん。
意味が無いと思うことでも、自分が知識が無いだけの場合も多いからな。
まっ本当に意味がないだけかも知れないが。
>>258
必ず一箇所にまとめられるわけでもないけどね。
必ず一箇所にまとめられるわけでもないけどね。
260 ：仕様書無しさん：2011/02/19(土) 23:38:54.63
例外使っても、あのアホが言うほどキレイにはならない。
あのアホがいうほどって、
どれだけキレイなコードなんだ？
どれだけキレイなコードなんだ？
262 ：仕様書無しさん：2011/02/19(土) 23:49:32.79
実際、そんなにキレイじゃなかっただろ。
むしろ、つぎはぎだらけのコードになるなアリャ
むしろ、つぎはぎだらけのコードになるなアリャ
アホがどうとかいうより、
きれいなコードってのが
どんなのかが気になるわけだが。
きれいなコードってのが
どんなのかが気になるわけだが。
はっきり言えるのは>>260がアホだってことだけだな。
266 ：仕様書無しさん：2011/02/20(日) 00:07:54.63
正常系と異常系にキレイに別れるとか言ってたから、
関数の最後に異常系が固まってるのかと思ったら・・・
関数の最後に異常系が固まってるのかと思ったら・・・
えっ…
綺麗に分かれるってのは
関数の最後に異常系がまとまるってことじゃねーだろｗ
正常系の処理の流れから
異常系が抜き出されるだけで。
関数の最後に異常系がまとまるってことじゃねーだろｗ
正常系の処理の流れから
異常系が抜き出されるだけで。
綺麗とか汚いとかそういう感覚的な部分で語るやつにろくな奴がいたためしがない
感覚じゃなくてちゃんと説明できるけど？
じゃあ結局、戻り値で条件分岐させた if 節と全く構成変わらんだろが。
正常系も異常系も混然一体となってるところは、全く変わってないじゃないか。
正常系も異常系も混然一体となってるところは、全く変わってないじゃないか。
どんだけ可読性が改善されるのかと思ったら、アレだもんな。
正直、その程度なのかって思ったわ。 オマエの程度が。
正直、その程度なのかって思ったわ。 オマエの程度が。
>同じ命令を使っていて、異常系を切り分けるifなのかどうか
>ぱっと見て分からんだろ。
普通は、コメントが書かれてますからｗ
>ぱっと見て分からんだろ。
普通は、コメントが書かれてますからｗ
if(check() ==1) {
/*エラーの場合*/
}
こんな感じか？ｗ
/*エラーの場合*/
}
こんな感じか？ｗ
あと、分からんようだから、イメージしてみろ。
正常系と異常系で、領域を色分けしてみ？ 例のコードは、シマシマになるんだよね。
正常系なら正常系、異常系な来場系ってな風に、視点をちょっといどうさせたら
知りたい情報がまとめて得られるようになってない。
工夫の足りない、読みにくいコードだよありゃ。
正常系と異常系で、領域を色分けしてみ？ 例のコードは、シマシマになるんだよね。
正常系なら正常系、異常系な来場系ってな風に、視点をちょっといどうさせたら
知りたい情報がまとめて得られるようになってない。
工夫の足りない、読みにくいコードだよありゃ。
× 異常系な来場系
○ 異常系なら異常系
○ 異常系なら異常系
コメントはコードの動きを説明するものではなくて、
なぜそうするのかを書くところなんだが・・・
try 〜 catch と書かれていれば、コードにこれは例外処理ですと書かれているような物。
コードに書いてある物を、コメントに書き写す意味はないよ。
だから例外を使っていればコメントは不要。
コメントを書きますからという時点で、
それはifが劣っているという証拠。
なぜそうするのかを書くところなんだが・・・
try 〜 catch と書かれていれば、コードにこれは例外処理ですと書かれているような物。
コードに書いてある物を、コメントに書き写す意味はないよ。
だから例外を使っていればコメントは不要。
コメントを書きますからという時点で、
それはifが劣っているという証拠。
例のコードってどのコード？
>if文はエラーを分岐させる命令じゃないだろ？
>正常系で、正常な処理の流れとして使われる命令だ。
>コメントはコードの動きを説明するものではなくて、
>なぜそうするのかを書くところなんだが・・・
オマエの俺様ルールを強要されても困るんだが。
>正常系で、正常な処理の流れとして使われる命令だ。
>コメントはコードの動きを説明するものではなくて、
>なぜそうするのかを書くところなんだが・・・
オマエの俺様ルールを強要されても困るんだが。
>コードに書いてある物を、コメントに書き写す意味はないよ。
あれ？ 順番が逆じゃないか？ 逆順なのも、最近提唱された手法か何かなのか？
あれ？ 順番が逆じゃないか？ 逆順なのも、最近提唱された手法か何かなのか？
コメントは、正しい手法に則るために書くんじゃなくて、正しく実装
して正しく保守するために書くべきではないかと。
どうせ数年経ったら言ってることがコロコロ変わってる学説とかに
準拠するためじゃないよ。
して正しく保守するために書くべきではないかと。
どうせ数年経ったら言ってることがコロコロ変わってる学説とかに
準拠するためじゃないよ。
頭でっかち君は、本当に職業プログラマーなのかな？
なにか言うたびにボロがでるよなｗ
今度はコメントの書き方に
ダメだしされてるし。
今度はコメントの書き方に
ダメだしされてるし。
いや、オマエの事なんだがｗ
>>288のことね。
あ、失礼。
誰が誰のことを言ってるかなんて
文章見ればわかるだろ。
ぼっこぼこにされてる一人と
その他大勢という構図なんだから。
文章見ればわかるだろ。
ぼっこぼこにされてる一人と
その他大勢という構図なんだから。
>>282
やっぱそれなのか。
あのコードが出てきた話の流れがさっぱり見えてないんだけど、
アレに対してコードが綺麗の汚いのってのは酷じゃない？
なんせただロールバックしてみただけで処理の大半が意味ないし、
ほぼ設計もしてないでしょアレ。
前スレからの流れか？
やっぱそれなのか。
あのコードが出てきた話の流れがさっぱり見えてないんだけど、
アレに対してコードが綺麗の汚いのってのは酷じゃない？
なんせただロールバックしてみただけで処理の大半が意味ないし、
ほぼ設計もしてないでしょアレ。
前スレからの流れか？
>>293
ぶっちゃけ、そういうの分かってて相手してる俺らも俺らだけどなｗ
>>294
例外でロールバック(リトライ)あたりの話題なのかなーって思ったけれど
そのあたりはだいぶ前にスレ内で解決してるし、対した意味があるものじゃなかったんじゃないかなー
ぶっちゃけ、そういうの分かってて相手してる俺らも俺らだけどなｗ
>>294
例外でロールバック(リトライ)あたりの話題なのかなーって思ったけれど
そのあたりはだいぶ前にスレ内で解決してるし、対した意味があるものじゃなかったんじゃないかなー
> try 〜 catch と書かれていれば、コードにこれは例外処理ですと書かれているような物。
ただそれだけ。正常系か異常系かはコード見ないとわからない。
ただそれだけ。正常系か異常系かはコード見ないとわからない。
異常系のコードを見るってどこを見る？
そう。try catchの場所ってすぐに分かるよね。
そう。try catchの場所ってすぐに分かるよね。
それが散財してたら、すぐには分からない。 アホ丸出し。
散財させなければいいじゃん？
散在
メソッド単位で考えて、異常系のパスはthrowしてる箇所で
catch内は異常系または準正常系
catch内は異常系または準正常系
異常系と正常系の分離ってのは綺麗だとか汚いだとかいう話じゃなくて、
コンパイラがそれらを認識して最適化に利用できると言うところが重要なんじゃないの？
この点で「コメントで済む」とか言うのはダメだし、「散在してたらすぐには分からない」って
いうのは例外に限らず単に読みにくいコードってだけで、コンパイラには確実に伝わって
いる。
コンパイラがそれらを認識して最適化に利用できると言うところが重要なんじゃないの？
この点で「コメントで済む」とか言うのはダメだし、「散在してたらすぐには分からない」って
いうのは例外に限らず単に読みにくいコードってだけで、コンパイラには確実に伝わって
いる。
>>303
そうでもない。
世の中の流れは、可読性も含む生産性をメインに置いてて、
パフォーマンスはハードで解決する方向になってる。
分野によってはそうじゃないのもあるだろうけど
。
まぁハードのスペックは、その考えに見合う程度に、
順調に上がってきてると思うよ。
そうでもない。
世の中の流れは、可読性も含む生産性をメインに置いてて、
パフォーマンスはハードで解決する方向になってる。
分野によってはそうじゃないのもあるだろうけど
。
まぁハードのスペックは、その考えに見合う程度に、
順調に上がってきてると思うよ。
ひとつの関数の中に散りばめられた正常系と異常系（笑）
なのに、
異常系は、一目瞭然（ｷﾘｯ
なのに、
異常系は、一目瞭然（ｷﾘｯ
>>305
ひとつの関数に散りばめなきゃいいじゃｎ
ひとつの関数に散りばめなきゃいいじゃｎ
多分、情報系のバカ学生が、ディベートの練習でもやっているのでしょう。
309 ：仕様書無しさん：2011/02/20(日) 13:51:43.08
ふふ、例外はスゲッとか言ってる御仁はスクリプトプログラムしか作れないのよ
ブラウザの例外表示が出るだけなら他に甚大なる被害は及ばないから
まあいいんじゃないの。ブラウザの中の箱庭スクリプト世界で例外最高って
言ってれば
ブラウザの例外表示が出るだけなら他に甚大なる被害は及ばないから
まあいいんじゃないの。ブラウザの中の箱庭スクリプト世界で例外最高って
言ってれば
いや、例外はスクリプト言語だけじゃなくて、
C++などのコンパイラ言語にもあるから。
っていうか今時ないのは、CとCOBOLぐらいでしょ。
C++などのコンパイラ言語にもあるから。
っていうか今時ないのは、CとCOBOLぐらいでしょ。
>>309
例外が出来た背景を知ってたら、そんなことは言えないはずなんだが
例外が出来た背景を知ってたら、そんなことは言えないはずなんだが
まぁ別に有り難がるほどには凄かないわな。
基本は同じ様な処理について、その処理の意味毎に
構文を変えられるようにしただけ。
だからどうやったら効果的に使えるかって話が
後追いで出てくんのよ。
その処理がその構文でしか書けない訳じゃないから。
基本は同じ様な処理について、その処理の意味毎に
構文を変えられるようにしただけ。
だからどうやったら効果的に使えるかって話が
後追いで出てくんのよ。
その処理がその構文でしか書けない訳じゃないから。
うん、極論すればアセンブラでなんでもできるしな。
問題はどれだけ分かりやすいか、
どれだけ簡単にできるか、
そういうこと、できるできないの話しているうちは
まだまださ。
問題はどれだけ分かりやすいか、
どれだけ簡単にできるか、
そういうこと、できるできないの話しているうちは
まだまださ。
314 ：おじゃばさま：2011/02/20(日) 14:48:42.35
>>310
なんかそうすると「例外」ってブスなくせにやたらしつこい
女みたいだな。
「おまえなんてどっか行け!」
って言っても
「嫌、あたなのそばにいてトイレにたれたおしっこのしずくを掃除するのっ」
って感じかな
なんかそうすると「例外」ってブスなくせにやたらしつこい
女みたいだな。
「おまえなんてどっか行け!」
って言っても
「嫌、あたなのそばにいてトイレにたれたおしっこのしずくを掃除するのっ」
って感じかな
負けず嫌いとかそういうのじゃなくてキチガイなんだと思う
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 以下、延々と続く
マナーの悪い人が多くなってしまったわけだ
馬鹿「うほっ、なんで例外が?? でも動いているし、スルーしちゃえ」
馬鹿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
戻り値でも例外でもエラー処理をきちんとできない「にせおじゃば」は糞だ
馬鹿「エラーチェック？めんどくさい。こんな所でエラー起きるわけ無いよ。」
馬鹿2「バグ？落ちてないからバグじゃないよ。」
馬鹿3「なんでこんな所で落ちてるんだ？このチェックいらね。なくても動いてるし」
馬鹿4 以下、延々と続く
馬鹿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
おじゃばさまって、
休みなのにすること無いのか？
しつこいやつだな。
休みなのにすること無いのか？
しつこいやつだな。
偽のほう、名前消し忘れてるぞ
329 ：おじゃばさま：2011/02/20(日) 15:53:57.53
偽おじゃばさまに言ったんだよ
330 ：おじゃばさま：2011/02/20(日) 16:01:25.84
それの何が悪いの？
一箇所直せば全部なおるじゃない。
それともあんたコピペしてんの？
一箇所直せば全部なおるじゃない。
それともあんたコピペしてんの？
332 ：おじゃばさま：2011/02/20(日) 16:29:43.82
一箇所のために修正したら、他の部分で不具合でたりするな。
だから基本コードを共有してはいけない。
関数なんてもってのほかだ。
だから基本コードを共有してはいけない。
関数なんてもってのほかだ。
>>332
それは、バグじゃなく仕様変更では？？？
それは、バグじゃなく仕様変更では？？？
そのときの追加・修正の仕方が
if(〜様向け対応){
追加・修正内容
}
がまとめたためにソースにたくさん入るようなまとめ方だと目も当てられないソースになる
上から下まで全部呼んで関係ない部分はずしてやっと意味がわかるソースもあるしね
強引に一箇所にまとめることはできるがまとめた後の管理まで考えるとちょっと考える面はある
一箇所にまとめたために上記のようなコードがたくさん入ってしまうなら
ぶっちゃけまとめないほうがよかった的ソースは経験したことないだろうか？
if(〜様向け対応){
追加・修正内容
}
がまとめたためにソースにたくさん入るようなまとめ方だと目も当てられないソースになる
上から下まで全部呼んで関係ない部分はずしてやっと意味がわかるソースもあるしね
強引に一箇所にまとめることはできるがまとめた後の管理まで考えるとちょっと考える面はある
一箇所にまとめたために上記のようなコードがたくさん入ってしまうなら
ぶっちゃけまとめないほうがよかった的ソースは経験したことないだろうか？
>>332
標準ライブラリ涙目。
標準ライブラリ涙目。
>>334
state/strategyパターンで解決
state/strategyパターンで解決
>>336
世の中の大半は「知らん」で片付けそうだな
世の中の大半は「知らん」で片付けそうだな
例外を理解出来ない人は
デザインパターンの領域にも
来れないだろうなｗ
デザインパターンの領域にも
来れないだろうなｗ
例外処理をポリモーフィズムできたら幾分まともになるかもしれない。
340 ：おじゃばさま：2011/02/20(日) 18:59:55.81
お前が言うなｗ
今日も一日中張り付いてたのかｗ
343 ：仕様書無しさん：2011/02/20(日) 22:38:21.04
>デザインパターンの領域
昔からある組合せのパターンを馬鹿にもわかるように体系化しただけ
昔からある組合せのパターンを馬鹿にもわかるように体系化しただけ
344 ：おじゃばさまオリジナル：2011/02/20(日) 22:41:09.44
246 ：おじゃばさま：2006/10/11(水) 09:17:00
「自分で調べろ」と言う先輩や上司の教えない理由は、
「知らない」か「教えるのが面倒」のどちらかだ。
新人教育の目的は「放置しても勝手に覚える人」に教える事ではなく、
「教えれば出来る人」や「教えないとやらない人」に教える事だ。
肉体労働ならともかく、プログラミングで若い人に負けると言うのは、
仕方ない事ではなくて、ただサボっているだけだ。
「自分で調べろ」と言う先輩や上司の教えない理由は、
「知らない」か「教えるのが面倒」のどちらかだ。
新人教育の目的は「放置しても勝手に覚える人」に教える事ではなく、
「教えれば出来る人」や「教えないとやらない人」に教える事だ。
肉体労働ならともかく、プログラミングで若い人に負けると言うのは、
仕方ない事ではなくて、ただサボっているだけだ。
5年も前のレス持ってきて何がしたいんだ？
というかなんでそんなこと覚えてるんだ
というかなんでそんなこと覚えてるんだ
言わせんな恥ずかしい
>>343
ある程度の知識があれば、それだけの話じゃないってことも分かるんだけどな
ある程度の知識があれば、それだけの話じゃないってことも分かるんだけどな
で、何の話してるんだ？
例外を分からない＝C言語どまり＝最新技術についてこれていない。
だから最新の話題をすると、そのすべてを否定するｗ
だから最新の話題をすると、そのすべてを否定するｗ
自分の頭で考えてないから、すぐに最新とか言い出すんだろうな。
あぁ、最新じゃないね。
実績のある普通の技術。
でも、そこまでも追いついていないから
全部否定する。
実績のある普通の技術。
でも、そこまでも追いついていないから
全部否定する。
でも例外を使うなってろくな理由もない主張は、自分が馬鹿って宣言してるようなもんだわなｗ
>>338
デザパタは作った奴がオブジェクト指向わかってねぇと思うんだけどな
実際の構造をそのままクラスに落とし込めばいいのであって
あんな妙ちくりんな構造にするメリットねぇじゃん
仕様変更かかったらかかったように直せばいいし
あのデザパタってのは一体何を想定した設計なのかさっぱりわからない
仕様書どおりの構造にクラス作ればいいじゃん
どの工程であんなもん入れる隙間があるのか本気でさっぱりわからない
デザパタは作った奴がオブジェクト指向わかってねぇと思うんだけどな
実際の構造をそのままクラスに落とし込めばいいのであって
あんな妙ちくりんな構造にするメリットねぇじゃん
仕様変更かかったらかかったように直せばいいし
あのデザパタってのは一体何を想定した設計なのかさっぱりわからない
仕様書どおりの構造にクラス作ればいいじゃん
どの工程であんなもん入れる隙間があるのか本気でさっぱりわからない
>>354
いいや、過去何度も議論したけど
そいつらは実際の構造をそのままクラスに反映させるようなセンスが欠落してる奴ばかりだった
だからデザパタなんて信仰しちゃうんだと思う
特にシングルトンなんてできる過程が意味不明じゃん（これに限らず他も意味不明だけどな）
この辺はセンスなのかな〜？
素直にクラスにすればいいのになんでかそれができないんだよね
これ信仰する人たちって・・・
いいや、過去何度も議論したけど
そいつらは実際の構造をそのままクラスに反映させるようなセンスが欠落してる奴ばかりだった
だからデザパタなんて信仰しちゃうんだと思う
特にシングルトンなんてできる過程が意味不明じゃん（これに限らず他も意味不明だけどな）
この辺はセンスなのかな〜？
素直にクラスにすればいいのになんでかそれができないんだよね
これ信仰する人たちって・・・
こっちのスレでそんな話をひっぱるんじゃねぇ。
>>357
そうやってあんまり関係無い方向から話を進めても結局行き着く先にはなにもないよｗ
そうやってあんまり関係無い方向から話を進めても結局行き着く先にはなにもないよｗ
まあ例外とOOはあんまり関係ないな。
色々模索してるのはわかるけど
普通に仕様書にある構造をそのままクラスに反映するのが一番なのに
なんでデザパタなんて割り込む隙があるのかわからない
デザパタ全部読んでもこれが書いてないんだよね
だから大抵の人間は「は？」って思う
「なんで？ふつーにそのままクラスにすりゃいいじゃん」と
これをわからずに○○手法、〜設計、□△図とか作りまくる開発未経験の著者or研究者達とか
この業界の癌にしかなってないと思う
奴等そもそも論文やら本やら書いてて開発やったことあるんだろうか？
普通に仕様書にある構造をそのままクラスに反映するのが一番なのに
なんでデザパタなんて割り込む隙があるのかわからない
デザパタ全部読んでもこれが書いてないんだよね
だから大抵の人間は「は？」って思う
「なんで？ふつーにそのままクラスにすりゃいいじゃん」と
これをわからずに○○手法、〜設計、□△図とか作りまくる開発未経験の著者or研究者達とか
この業界の癌にしかなってないと思う
奴等そもそも論文やら本やら書いてて開発やったことあるんだろうか？
>>361
で、それが例外の使い方という側面から見て、何なの？
で、それが例外の使い方という側面から見て、何なの？
>>364
お前、頭パーだからそんなもん妄信してんだろ
お前、頭パーだからそんなもん妄信してんだろ
>>305
width = config["width"].toInt();
height = config["height"].toInt();
こんな風に設定情報を読み取りたいとする。
この時整数じゃない項目を全て列挙し、エラー情報に
乗せなきゃいけない。
君ならどう例外処理する?
※上のコードは例であって
項目は複数あるものとする
width = config["width"].toInt();
height = config["height"].toInt();
こんな風に設定情報を読み取りたいとする。
この時整数じゃない項目を全て列挙し、エラー情報に
乗せなきゃいけない。
君ならどう例外処理する?
※上のコードは例であって
項目は複数あるものとする
>>366
横からだけどコードから言って意味不明なんだけど
横からだけどコードから言って意味不明なんだけど
>>366
foreach(item in config) { try-catch ]
foreach(item in config) { try-catch ]
現実と異なる構造にしたら、現実の構造が変わった時とか、特殊事例が
出てきた時に、どうやって対処していくつもりなんだろ。
現実世界での解決方法が、そのまま適用できなくなっていくじゃん。
出てきた時に、どうやって対処していくつもりなんだろ。
現実世界での解決方法が、そのまま適用できなくなっていくじゃん。
ぼくちゃんのオナニーに、御社の業務は合わせるべき（ｷﾘｯ
仕様書をどんなものと捉えてるかによる気がするなー。
もし、設計書のことを仕様書と言ってるようだと、設計書どおりにクラス起こすのが当然。
もし、設計書のことを仕様書と言ってるようだと、設計書どおりにクラス起こすのが当然。
こいつ、顧客がカネ払って買ってくれるプログラムを実際に作ったことねーわ
何が手段で、何が目的なんだか。
デザインパターン（笑）を使って顧客の要求を矯正（笑）
>>377
デザパタ適用するために設計いじるとかいってる馬鹿は相手にできないなｗ
デザパタ適用するために設計いじるとかいってる馬鹿は相手にできないなｗ
>>378は顧客が設計までしてくれる環境なんだろうな。
そりゃ、顧客の設計を否定するわけにはいかんわな。
そりゃ、顧客の設計を否定するわけにはいかんわな。
デザパタ（笑）肯定派意味わかんね
設計したことないとわかんないだろうね。
って、PGじゃ設計しないか。
って、PGじゃ設計しないか。
全ての発想と手法が、社会常識と正反対だなｗ
そのまま素直に仕様書に書いてあるもんクラスにすりゃいいのに
まず、はじめにデザパタの適用からはじめちゃうキチガイだから
何発言しても驚かないよ
まず、はじめにデザパタの適用からはじめちゃうキチガイだから
何発言しても驚かないよ
>>384
仕様書に書いてあるのをクラスにして終わりっていうレベルだと必要ないかもな。
仕様書に書いてあるのをクラスにして終わりっていうレベルだと必要ないかもな。
なんや、おどれ、森羅万象を設計してくれるのけ？
>>385
レベルが高くなるとお前のオナニーを実現するための意味不明な中間クラス（笑）がたくさん増えるんだ？
レベルが高くなるとお前のオナニーを実現するための意味不明な中間クラス（笑）がたくさん増えるんだ？
オナニーは必要ない
>>389
「ぼくが考えた設計」がオナニーじゃないことの方が珍しいと思うぞw
「ぼくが考えた設計」がオナニーじゃないことの方が珍しいと思うぞw
ところで、自然科学分野のシミュレーションプログラムって、オナニー野郎の
デザインパターン適用できるのだろうか？
デザインパターン適用できるのだろうか？
クラス変更の影響範囲を切る手法がほとんどだから、
規模が小さかったり、変更がおよそ有り得ないなら
使わんでもいいだろ。
規模が小さかったり、変更がおよそ有り得ないなら
使わんでもいいだろ。
デザインパターンが、世の中の全ての現象を網羅して考案されているとは思えない。
ごく限られた領域でのみ、たまたまうまく適用できている事例が点在しているだけだろ。
ごく限られた領域でのみ、たまたまうまく適用できている事例が点在しているだけだろ。
>>393
うまく適応できる事例は使った方がいいね。
デザインパターン使わずに考えたら、既存のデザインパターンに似た設計になりました
みたいな車輪の再発明して喜ぶのは本末転倒だし。
べつに、なんでもデザインパターン適応したほうがいいとは言ってないよ。
うまく適応できる事例は使った方がいいね。
デザインパターン使わずに考えたら、既存のデザインパターンに似た設計になりました
みたいな車輪の再発明して喜ぶのは本末転倒だし。
べつに、なんでもデザインパターン適応したほうがいいとは言ってないよ。
>既存のデザインパターンに似た設計
バカの発言ｋｔｋｒ
バカの発言ｋｔｋｒ
>>361
http://d.hatena.ne.jp/asakichy/20090213/1234485643
もっと詳しく知りたい方は「GRASP」で検索してみてください。
>>394
デザインパターンはよく使うパターンに名前をつけたものなので似た設計に
なるのはよくあることです。
http://d.hatena.ne.jp/asakichy/20090213/1234485643
もっと詳しく知りたい方は「GRASP」で検索してみてください。
>>394
デザインパターンはよく使うパターンに名前をつけたものなので似た設計に
なるのはよくあることです。
>>397
四十八手の名前知らなくても、ちゃんとまともにセックスできるだろｗ
四十八手の名前知らなくても、ちゃんとまともにセックスできるだろｗ
下品な奴だな
卑近な例で、分かりやすく説明しただけだが。
デザインパターンは慣用句。知っていれば表現の幅が広がる。
デザパタ知らなくても、自然に落とし込んでたら
デコレーターになってたりするんだがな。
デコレーターになってたりするんだがな。
でっていう
>>402
完全に下流の工程しか担当しない(リファクタリングの権限がない)のなら仕様書を
そのままクラスに起こすのが正しいと思います。
レビューに参加しているのであればその場で提案します。一人で勝手にすべての構造を決めるわけではないので
(パターン中毒者の存在は否定しませんが)パターン中毒者のオナニーばかりという訳ではありませんよ
完全に下流の工程しか担当しない(リファクタリングの権限がない)のなら仕様書を
そのままクラスに起こすのが正しいと思います。
レビューに参加しているのであればその場で提案します。一人で勝手にすべての構造を決めるわけではないので
(パターン中毒者の存在は否定しませんが)パターン中毒者のオナニーばかりという訳ではありませんよ
そうやってクソシステムが量産されるんですね。わかります。
まだ無知が自分の知らない世界を否定し続けてるのか。
三平方の定理が役に立たないとほざく中学生と同じレベルだと気付かんのかね。
三平方の定理が役に立たないとほざく中学生と同じレベルだと気付かんのかね。
あー、お前さんは、いろいろちゃんと考えてるんですね。 角度とか。
単純に疑問なんですが、否定派の方は
同じ用途で複数の外部システムと連携するようなシステムを開発する際に
どうしてるんですか？状態変数をみてifやswitchですか？
同じ用途で複数の外部システムと連携するようなシステムを開発する際に
どうしてるんですか？状態変数をみてifやswitchですか？
>>369
まぁ、そう思うだろ。最初俺もそう思った。
でも、よく考えたら、例外にするより
事前チェックの方が効率が悪いんだよ
。
まず、正常時だと数字変換が2回行われる。
それから、例外時だと事前チェックも例外機構使用時も
同じ情報集める必要がある。
さらに事前チェックだと、取得する変数が変わった時に
2箇所も直さなきゃならん。
事前チェックで得すんのは、例外状態での速度だけなんだ。
あとレス番間違えた
×305
○306
まぁ、そう思うだろ。最初俺もそう思った。
でも、よく考えたら、例外にするより
事前チェックの方が効率が悪いんだよ
。
まず、正常時だと数字変換が2回行われる。
それから、例外時だと事前チェックも例外機構使用時も
同じ情報集める必要がある。
さらに事前チェックだと、取得する変数が変わった時に
2箇所も直さなきゃならん。
事前チェックで得すんのは、例外状態での速度だけなんだ。
あとレス番間違えた
×305
○306
なんで自分の知らないものを否定するんですか？
で、何秒得するの？
多分、誰も例外やデザパタを否定してるんじゃないと思うよ？
誰かさんのロクでもねー人格だけを否定してるんだと思うよ？
誰かさんのロクでもねー人格だけを否定してるんだと思うよ？
いやー、本当に想定通りの流れになってるなｗ
どうせ例外を知らないやつは、新しく・・・もないが
C言語の時代からすれば、新しくて、今普通に使われてる技術を
全て知らないだろうから、
知らない物＝全部否定 脳 だろうと仮定して、
デザパタの話題を振ったのだが、想定通り否定してるなｗ
今度はユニットテストの話でもしようか？
ついてこれないだろう？ｗ
どうせ例外を知らないやつは、新しく・・・もないが
C言語の時代からすれば、新しくて、今普通に使われてる技術を
全て知らないだろうから、
知らない物＝全部否定 脳 だろうと仮定して、
デザパタの話題を振ったのだが、想定通り否定してるなｗ
今度はユニットテストの話でもしようか？
ついてこれないだろう？ｗ
C言語厨ってテストの自動化ってやってるの？
>>414
例外もデザパタもUTも否定しないが、お前は否定する。
例外もデザパタもUTも否定しないが、お前は否定する。
想定通りだってｗ
>>415
ふつうにやるけど。やらないとめんどくせーし。
ふつうにやるけど。やらないとめんどくせーし。
すべてのことが事前に分かれば事前チェックは可能だが、
たとえばファイル読み込みとか、事前にチェックしたとしても、
チェックした後でファイルが無くなるとかあり得るからな。
結局は例外に頼ることになるという。
たとえばファイル読み込みとか、事前にチェックしたとしても、
チェックした後でファイルが無くなるとかあり得るからな。
結局は例外に頼ることになるという。
>>420
そりゃ、ファイルが無いという例外が飛んでくる環境ではそうだろうよ。
そりゃ、ファイルが無いという例外が飛んでくる環境ではそうだろうよ。
この場合、例外が飛んで来るというのは素晴らしい機能なんだよね。
事前にチェックしたのだから、ファイルがあることは確実だろう。
なんて初心者は思い込んで、ファイルをオープンした後の
戻り値チェック省いてしまう。
いわゆるバグなんだけど、例外だとこんな場合でもエラーを
無視することはないので、エラーに気づくことができるんだよ。
事前にチェックしたのだから、ファイルがあることは確実だろう。
なんて初心者は思い込んで、ファイルをオープンした後の
戻り値チェック省いてしまう。
いわゆるバグなんだけど、例外だとこんな場合でもエラーを
無視することはないので、エラーに気づくことができるんだよ。
何スレか前から見てるけど、例外が起きる例として、ファイルアクセス
関連の話しか出てこないんだがｗ
関連の話しか出てこないんだがｗ
速度が求められることって意外とないんで、
普通のお仕事ならば入力時も読み取り時も両方チェックするのがいいと思う
普通のお仕事ならば入力時も読み取り時も両方チェックするのがいいと思う
それにオマエの話だと、あるプログラムのメモリ上でだけの不都合な事象でも、
例外投げてウハウハみたいなはしゃぎっぷりだったんだがｗ
例外投げてウハウハみたいなはしゃぎっぷりだったんだがｗ
別にメモリとファイルを区別する必要もないけどね。
データが揮発性かどうかってだけの違いだし。
メモリマップトファイルみたいなものもあるし、
実は二つを区別して考える必要性は少ない。
データが揮発性かどうかってだけの違いだし。
メモリマップトファイルみたいなものもあるし、
実は二つを区別して考える必要性は少ない。
>別にメモリとファイルを区別する必要もないけどね。
>メモリマップトファイルみたいなものもあるし
どこまで行ってもファイルの話しかしないのなｗ 多分、日本語が苦手なんだろうなｗ
>メモリマップトファイルみたいなものもあるし
どこまで行ってもファイルの話しかしないのなｗ 多分、日本語が苦手なんだろうなｗ
事前チェックは最適化の範疇だと考えればいいんだよ。
特にやる必要はないけど、重視する必要がある場合のみ
対応する。
特にやる必要はないけど、重視する必要がある場合のみ
対応する。
>事前チェックは最適化の範疇だと考えればいいんだよ。
俺様ルールｋｔｋｒ
俺様ルールｋｔｋｒ
>>430
仮想メモリって知ってる？
仮想メモリって知ってる？
>>433
相手の意図をくみとって意思疎通する能力が、著しく欠乏している障害者乙。
相手の意図をくみとって意思疎通する能力が、著しく欠乏している障害者乙。
仮想メモリのファイルを、誰かに消されていたでござる（ｷﾘｯ
すげぇ勢いだなこのスレ。
数十レス斜め読みしたけど、誰がどの主張してるか全然分からん。
そろそろ誰かまとめてくれ。
数十レス斜め読みしたけど、誰がどの主張してるか全然分からん。
そろそろ誰かまとめてくれ。
まぁ、プログラミングの作法について、なんらかの意見があるならマシだろ。
ひどいのは、マジでなんも考えてない奴ｗ
１０年選手とか言ってても１年選手より使えねぇーのがいっぱい。
ひどいのは、マジでなんも考えてない奴ｗ
１０年選手とか言ってても１年選手より使えねぇーのがいっぱい。
と、一年選手がホザいています
なんだ、駆け出し君がキャンキャン吠えてたのかｗ
442 ：仕様書無しさん：2011/02/21(月) 22:56:34.40
職業プログラマーらしからぬ発言だらけだったから、おかしいと思ってたんだよね。
そしたら案の定、ペーペー君だった訳だ。
そしたら案の定、ペーペー君だった訳だ。
基本的に、例外でエラー処理（事前に判定出来る物）をしてはいけない。
しかし、発生場所が複数で対応方法を同一にしたいエラーは
例外にマッピングして一箇所で処理をする。
例外は発生する場所より、それを受止める場所が大事。
将来の事を考えOCPでしっかりと設計しなければならない。
しかし、発生場所が複数で対応方法を同一にしたいエラーは
例外にマッピングして一箇所で処理をする。
例外は発生する場所より、それを受止める場所が大事。
将来の事を考えOCPでしっかりと設計しなければならない。
444 ：仕様書無しさん：2011/02/21(月) 23:11:34.74
>>441
自分がいつも先輩から言われているセリフを、他人に言ってみました（ｷﾘｯ
自分がいつも先輩から言われているセリフを、他人に言ってみました（ｷﾘｯ
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
自分がいつも先輩から言われているセリフを、他人に言ってみました（ｷﾘｯ
職業プログラマーらしからぬ発言だらけだったから、おかしいと思ってたんだよね。
そしたら案の定、ペーペー君だった訳だ。
443 名前： 仕様書無しさん [sage] 投稿日： 2011/02/21(月) 23:08:34.24
基本的に、例外でエラー処理（事前に判定出来る物）をしてはいけない。
しかし、発生場所が複数で対応方法を同一にしたいエラーは
例外にマッピングして一箇所で処理をする。
例外は発生する場所より、それを受止める場所が大事。
将来の事を考えOCPでしっかりと設計しなければならない。
444 名前： 仕様書無しさん 投稿日： 2011/02/21(月) 23:11:34.74
>>441
自分がいつも先輩から言われているセリフを、他人に言ってみました（ｷﾘｯ
自分がコレまでやってきた底辺作業を至高の仕事だったって思ってるんだから
新しいこととか、そういうのを覚えようとは思わんのでしょ
例外は新しかねーけど、それでも、当たり前に使えない奴多いしな
自分も新しいこと全部理解できてるってほど勉強してるとは思わんけど
ろくに知りもせず、あまり理解できないから否定してる奴は単純に馬鹿なんだと思うよ
根拠の出せない無駄認定や、(理解してないから)めんどくさいみたいな否定ばっかで
メリットデメリット語ってるやつはほぼ居ないしな
新しいこととか、そういうのを覚えようとは思わんのでしょ
例外は新しかねーけど、それでも、当たり前に使えない奴多いしな
自分も新しいこと全部理解できてるってほど勉強してるとは思わんけど
ろくに知りもせず、あまり理解できないから否定してる奴は単純に馬鹿なんだと思うよ
根拠の出せない無駄認定や、(理解してないから)めんどくさいみたいな否定ばっかで
メリットデメリット語ってるやつはほぼ居ないしな
>>442
職業マとか糞の塊じゃねーかｗ
工事現場で車の誘導するプロです！ってしたり顔で語られてもな
既に土方根性が染み付いてそうな語り口だし、言うだけ無駄だろうけど
tester-doerの話が出てるけど、例えば文字パースする場合、俺はそのままparseするなぁ
もちろんC#とかならTryParseするけど、用意されてない方が多いし
既存の機能だけで判断できるのに、わざわざチェック処理を再発明するなんて無駄の極み
失敗がある処理ならtryして失敗したらそんときの振る舞いを書く、ただそんだけのことじゃん
設計まで手がけてりゃいろいろ考慮必要だけど、ここで例外についてぐだぐだ言ってる土方じゃ
その手のことを任せられるような人じゃなさそうだしなー
職業マとか糞の塊じゃねーかｗ
工事現場で車の誘導するプロです！ってしたり顔で語られてもな
既に土方根性が染み付いてそうな語り口だし、言うだけ無駄だろうけど
tester-doerの話が出てるけど、例えば文字パースする場合、俺はそのままparseするなぁ
もちろんC#とかならTryParseするけど、用意されてない方が多いし
既存の機能だけで判断できるのに、わざわざチェック処理を再発明するなんて無駄の極み
失敗がある処理ならtryして失敗したらそんときの振る舞いを書く、ただそんだけのことじゃん
設計まで手がけてりゃいろいろ考慮必要だけど、ここで例外についてぐだぐだ言ってる土方じゃ
その手のことを任せられるような人じゃなさそうだしなー
職業PGにろくな奴がいないのは同意。
特に年食った奴。使えない上に頭は固い。不勉強なのに自尊心だけは一人前。
人手不足でしょうがなく使ってみたけど、邪魔にしかならんから即クビだったわ。
特に年食った奴。使えない上に頭は固い。不勉強なのに自尊心だけは一人前。
人手不足でしょうがなく使ってみたけど、邪魔にしかならんから即クビだったわ。
技術的反論が出来ない人間は、人を批判する。
人格否定から入る奴いるよね
>>421
じゃtryなメソッドとやらの具体的なコードを見せてくれ。
あと例外機構はreturnでまともな値を返すための代替構文だ。
try catch型は元々オペレーターのオーバロードを綺麗に
書くこととコンストラクターの異常通知が発端になってる。
禿げのC++関連書籍を読んでみろ。
じゃtryなメソッドとやらの具体的なコードを見せてくれ。
あと例外機構はreturnでまともな値を返すための代替構文だ。
try catch型は元々オペレーターのオーバロードを綺麗に
書くこととコンストラクターの異常通知が発端になってる。
禿げのC++関連書籍を読んでみろ。
452 ：仕様書無しさん：2011/02/22(火) 18:20:01.86
今日もまた、残念な人格のアホタレが口でクソ垂れてるなｗ
>>451
物の役割は時代と共に変わる
物の役割は時代と共に変わる
>>453
ifの役割が変わったか?
forの役割が変わったか？
switchの役割が変わったか？
returnの役割が変わったか？
詭弁も大概にしろ。
言語設計事時の役割が変わる事はまずあり得ん。
有るとすれば仕様の改変が行われたときだ。
仕様が変わらないのに変わったようにおもえるなら、
何が起因してどう変わったのか書いてみろよ。
ifの役割が変わったか?
forの役割が変わったか？
switchの役割が変わったか？
returnの役割が変わったか？
詭弁も大概にしろ。
言語設計事時の役割が変わる事はまずあり得ん。
有るとすれば仕様の改変が行われたときだ。
仕様が変わらないのに変わったようにおもえるなら、
何が起因してどう変わったのか書いてみろよ。
>454
てか、例外の歴史は知んないけどさ。
次々に新しい言語が開発されてんだから
その都度言語設計はされてんじゃん。
forはeachが出て来てカウンティングの
意味合いが強くなったりしたし、
switchはフォールスルーが禁止されて
よりif寄りになったりしてるよ。
てか、例外の歴史は知んないけどさ。
次々に新しい言語が開発されてんだから
その都度言語設計はされてんじゃん。
forはeachが出て来てカウンティングの
意味合いが強くなったりしたし、
switchはフォールスルーが禁止されて
よりif寄りになったりしてるよ。
456 ：仕様書無しさん：2011/02/22(火) 22:51:13.66
予想以上に反響が大きいこのスレは例外に該当するの？？
レベルが高いのか低いのか分からんが
とにかく俺には着いていけない話だ。
とにかく俺には着いていけない話だ。
言語の仕様はいい方向には変わるが
悪い方向には変わらないよ。
ということで、戻り値でエラーを返す方式よりも
後にできた例外でエラーを返す方式は
戻り値でエラーを返す方式には戻らない。
もし例外よりもいいものが出来れば、その時は例外はなくなるかもしれないが、
戻り値に戻ることはないし、例外よりも優れたものは今のところ出来ていない。
言語の仕様が変わることがあるんだから、例外も変わると詭弁は要らない。
言語の仕様が変わるという現象が、果たして例外に当てはまるのかどうかの話をするべきだ。
悪い方向には変わらないよ。
ということで、戻り値でエラーを返す方式よりも
後にできた例外でエラーを返す方式は
戻り値でエラーを返す方式には戻らない。
もし例外よりもいいものが出来れば、その時は例外はなくなるかもしれないが、
戻り値に戻ることはないし、例外よりも優れたものは今のところ出来ていない。
言語の仕様が変わることがあるんだから、例外も変わると詭弁は要らない。
言語の仕様が変わるという現象が、果たして例外に当てはまるのかどうかの話をするべきだ。
>>460
知らんがな。
じゃあ>>454でそう書けよって話だよ。
まぁ検査例外は評判悪いみたいだけどなぁ。
ああいうのはわりと好きなんだけど、
JAVA使ってないから聞いた話しか分からない。
もうちょっと洗練されて流行るのか、
淘汰されて消えるのか。
知らんがな。
じゃあ>>454でそう書けよって話だよ。
まぁ検査例外は評判悪いみたいだけどなぁ。
ああいうのはわりと好きなんだけど、
JAVA使ってないから聞いた話しか分からない。
もうちょっと洗練されて流行るのか、
淘汰されて消えるのか。
>>455
お前の言ってる範囲じゃforもswitch意味合いは変わってない。
お前が言ってるのは、
javascriptやpythonは、アクセス制御がないからあのオブジェクト機能は、
オブジェクト思考とは違うって言ってんのと変わらん。
言語設計者は利便性のため今までと
多少異なる手段を取るが、
目指す機能は一貫してて、同じ
セマンティクスを保たせている。
じゃお前の言う役割が変わるってなんだよって思うだろうが、
それに答えるならクラスと構造体だ。
C++なんかじゃ
構文上両者殆ど差が無い。しかし、意味合いが全く違う。
クラスが構造体を拡張して利用しているのは、
手段であって目的じゃない。オブジェクト思考は構造体に関数を
くくりつける事じゃない。
完全にセマンティクスが別なんだ。
これが俺の言う役割の違い。
じゃ、例外にそんな事起きたか?
スタックトレースやら、送出チェックやら多少の拡張は
有ったがなんらセマンティクスは変わって無いだろ。
お前の言ってる範囲じゃforもswitch意味合いは変わってない。
お前が言ってるのは、
javascriptやpythonは、アクセス制御がないからあのオブジェクト機能は、
オブジェクト思考とは違うって言ってんのと変わらん。
言語設計者は利便性のため今までと
多少異なる手段を取るが、
目指す機能は一貫してて、同じ
セマンティクスを保たせている。
じゃお前の言う役割が変わるってなんだよって思うだろうが、
それに答えるならクラスと構造体だ。
C++なんかじゃ
構文上両者殆ど差が無い。しかし、意味合いが全く違う。
クラスが構造体を拡張して利用しているのは、
手段であって目的じゃない。オブジェクト思考は構造体に関数を
くくりつける事じゃない。
完全にセマンティクスが別なんだ。
これが俺の言う役割の違い。
じゃ、例外にそんな事起きたか?
スタックトレースやら、送出チェックやら多少の拡張は
有ったがなんらセマンティクスは変わって無いだろ。
論点がぼやけるのは、いつものこと
セマンティクスやコンテクストという言葉は、意味が通るようで全く分からん。
コンテスト=脈絡
状態の変化していく過程
プログラミング界隈ではコンテスト情報の意味が混在してる。
セマンティクス=それが存在する意図
例えば、nullはnullポエラーで
プログラマーが苦しみハゲ散らかすために作られたんじゃない。
存在しない事を表すために作られた。
この存在しない事を表すためという
のがセマンティクス。
他にも、CにGotoが残っているがfor等代替構文が用意されている。
この場合不必要にGotoを使うなというのがセマンティクス。
この意図を無視する事をセマンティクスに反するという。
状態の変化していく過程
プログラミング界隈ではコンテスト情報の意味が混在してる。
セマンティクス=それが存在する意図
例えば、nullはnullポエラーで
プログラマーが苦しみハゲ散らかすために作られたんじゃない。
存在しない事を表すために作られた。
この存在しない事を表すためという
のがセマンティクス。
他にも、CにGotoが残っているがfor等代替構文が用意されている。
この場合不必要にGotoを使うなというのがセマンティクス。
この意図を無視する事をセマンティクスに反するという。
ミスコンテスト
そいつぁ美人が集まりそうだ
ミス 例外を正しく使えるプログラマ コンテスト
ああ悪かったよ。携帯からの予測変換でよく見てなかった。
いちいち横文字使わずに、日本語で正しく表現してみろや。
セックスとまではちぢまらねぇかｗ
あの表現に嫉妬してんのか。精進せえよ。
日常使うかって言われたら俺は使わんけど
別に意味が分からない単語ではないし、いちいち突っかかるような事でもないわ
別に意味が分からない単語ではないし、いちいち突っかかるような事でもないわ
発音しないだけで、脳内では常に意識しているくせに
計量はメトリクス、群はグループ
デジタルは離散量、クラスは類
ツッコミ入れるならおちつけよ
デジタルは離散量、クラスは類
ツッコミ入れるならおちつけよ
俺のビッグコックをヤングレディーにインサートしてヒィヒィ言わせたい
そんなしょうもない辞書があるのかw
なるほど、科学力がズタズタになってゆくわけだ。
なんか、過疎ってきたな
戻り値厨が一人いなくなるだけで
こうななるのさｗ
こうななるのさｗ
日によってプログラムの書き方が変わるって精神分裂病だよ
誰もそんな話してないだろ。
お前が精神分裂病なのか？
お前が精神分裂病なのか？
例外中は、例外ばっかり投げてるお騒がせ野郎。
戻ってきたなら、
ちゃんとただいまっていえや。
かまってやらんぞ。
ちゃんとただいまっていえや。
かまってやらんぞ。
何を言っても馬鹿を露呈するだけの無能だから、
>>485みたいな定型文の煽り文句程度しか書けること残ってないんだよ(´･ω･`)
>>485みたいな定型文の煽り文句程度しか書けること残ってないんだよ(´･ω･`)
そんなに怖がらなくてもいいのに
ただ単に頭が悪いだけじゃないの
catchの中身になにも書かなければ握りつぶしたことになると思ってたけど
C#ってならないんだ
ちなみに正解は何を書けばいいの？
C#ってならないんだ
ちなみに正解は何を書けばいいの？
492 ：仕様書無しさん：2011/02/27(日) 12:58:32.92
例外自体はそれほど重要じゃない話なんだけど、
ちょっと頭の体操。
交点座標を求める関数型IS作るとする。
交点の座標を戻り値ないし、引数で返す。
この時、交点を求める基準となる二つの直線(ベクター)が
平行なら交点座標は不定となる。
さて、君らなら、このISをどうやって実装する?
ヒント
2次関数の解をどうやって表す？
cosなどの周期関数を因数分解したときの答えは?
ちょっと頭の体操。
交点座標を求める関数型IS作るとする。
交点の座標を戻り値ないし、引数で返す。
この時、交点を求める基準となる二つの直線(ベクター)が
平行なら交点座標は不定となる。
さて、君らなら、このISをどうやって実装する?
ヒント
2次関数の解をどうやって表す？
cosなどの周期関数を因数分解したときの答えは?
外積。完全にスレ違いと思う
494 ：仕様書無しさん：2011/02/27(日) 13:29:04.00
>>493
ごめん。式自体はどうでもいい。
問題は関数のインターフェースね。
どうやって値を返すかって話。
nullを返すなり例外だしたり、
戻り値bool返したり色々あると
思うけどどうするかって話。
ごめん。式自体はどうでもいい。
問題は関数のインターフェースね。
どうやって値を返すかって話。
nullを返すなり例外だしたり、
戻り値bool返したり色々あると
思うけどどうするかって話。
返したい情報を持つクラス。完全にスレ違いと思う
496 ：仕様書無しさん：2011/02/27(日) 14:10:21.46
>>495
どんなクラス？
不定情報と座標情報を持ってるとか？
具体的に教えてくれ。
別に例外機構は関係ないけど、分野としては
例外処理なんだけどな。
スレタイもあくまで例外機構ではないし。
ま、小さい概念だけだと例外で
大きくみた実装は異なるって話で
広げたかったんだけどな。
どんなクラス？
不定情報と座標情報を持ってるとか？
具体的に教えてくれ。
別に例外機構は関係ないけど、分野としては
例外処理なんだけどな。
スレタイもあくまで例外機構ではないし。
ま、小さい概念だけだと例外で
大きくみた実装は異なるって話で
広げたかったんだけどな。
じゃあスレ立ててよそでやろうね。完全にスレ違いだと思う
そういう後出しジャンケンみたいなのはダメだろ。
話ひろげたきゃまず自分で出せよ。
話ひろげたきゃまず自分で出せよ。
>>492
交点は無限遠点とする。
交点は無限遠点とする。
烏丸通と河原町通は、北極と南極で交差する。
>>496
>別に例外機構は関係ないけど、分野としては
>例外処理なんだけどな。
なぜ例外になるんだ？ お前の数学の知識はその程度なのか？
その答えが例外だと思っている時点で、数学・システム工学についての知識が薄いことは分かった。
>別に例外機構は関係ないけど、分野としては
>例外処理なんだけどな。
なぜ例外になるんだ？ お前の数学の知識はその程度なのか？
その答えが例外だと思っている時点で、数学・システム工学についての知識が薄いことは分かった。
おじゃば乙。
具体的にどうするか論破して、どっかのスレに帰れ的な
レスが付くと思ったが、この程度か。がっかりだな。
結論として、意外に例外扱いしそうでも、しなくていいケースが
潜在してるってとこに持って行きたかったんだけどなぁ。
とりあえず模範解答を出せば、配列で返すだ。要素数の
概念があれば別にリストだろうがなんで構わんけど。
交点が出せれば要素は1、出せなければ要素数は0になる。
で、これが配列で有るために因数分解の解と互換性を持たせられる。
これらの結果は全て配列で表現できるとね。まぁ、cosの
因数分解については無限になるから、配列をオーバーライドして
添字に合わせた
解を取り出せるよう工夫が必要になるけどね。
次第点としては、予め交差してなかった場合返す座標を
引数に渡し交差していなければそれを返す。状況によっては
無駄な先読みが必要になるのであまり宜しく無い。
他、例外的手法。事前チェック、
座標と正否値を返す。それこそ例外機構を使う等考えられるが、無駄や値の完全性という点から見て総じてアウト。
レスが付くと思ったが、この程度か。がっかりだな。
結論として、意外に例外扱いしそうでも、しなくていいケースが
潜在してるってとこに持って行きたかったんだけどなぁ。
とりあえず模範解答を出せば、配列で返すだ。要素数の
概念があれば別にリストだろうがなんで構わんけど。
交点が出せれば要素は1、出せなければ要素数は0になる。
で、これが配列で有るために因数分解の解と互換性を持たせられる。
これらの結果は全て配列で表現できるとね。まぁ、cosの
因数分解については無限になるから、配列をオーバーライドして
添字に合わせた
解を取り出せるよう工夫が必要になるけどね。
次第点としては、予め交差してなかった場合返す座標を
引数に渡し交差していなければそれを返す。状況によっては
無駄な先読みが必要になるのであまり宜しく無い。
他、例外的手法。事前チェック、
座標と正否値を返す。それこそ例外機構を使う等考えられるが、無駄や値の完全性という点から見て総じてアウト。
>>503
y-2x = 0と2y - 4x = 0の交点は？
y-2x = 0と2y - 4x = 0の交点は？
>>504
平行線というか、同じ直線上にあるから、無限でもあるし、存在しないとも言える。
普通存在しないと考える。
どうしても必要なら配列をラムダ化して遅延評価を使う。
ま、直線自体はベクトルだしな。
平行線というか、同じ直線上にあるから、無限でもあるし、存在しないとも言える。
普通存在しないと考える。
どうしても必要なら配列をラムダ化して遅延評価を使う。
ま、直線自体はベクトルだしな。
だから、同次座標使えと。
で、その話と例外と、どう関連付けたいんだ？
いっつも話が横道にそれておかしな事になるよなｗ
まだあのアホな話題続けてたのね
答えありきで例題(笑)を考えて、お前ら答えてみろって言ってみたものの即スレチだとあしらわれ、
相手にされなかったら勝利宣言だしてしたり顔…。痛い子のテンプレートみたいだなｗ
戻り値の型についても、例外にする条件についても、事前に儲ける必要のある制約次第ってだけ。
だから情報の足りない提示された前提だけじゃ、プログラム上での表現方法なんていくらでも想定できる。
問題不備な時点で、必要な情報を表せる型を返す以上の具体的な表現には意味なんかねーよ。
むしろ配列が模範解答とか言っちゃう時点で…ｗ
答えありきで例題(笑)を考えて、お前ら答えてみろって言ってみたものの即スレチだとあしらわれ、
相手にされなかったら勝利宣言だしてしたり顔…。痛い子のテンプレートみたいだなｗ
戻り値の型についても、例外にする条件についても、事前に儲ける必要のある制約次第ってだけ。
だから情報の足りない提示された前提だけじゃ、プログラム上での表現方法なんていくらでも想定できる。
問題不備な時点で、必要な情報を表せる型を返す以上の具体的な表現には意味なんかねーよ。
むしろ配列が模範解答とか言っちゃう時点で…ｗ
答えありきで、って部分は訂正
具体例に落とすには、まず何を求めるかを明確にする必要があるのに
それをやらずに答えてみろっていう問題が問題だっていう話
仕様を提案しながら固めるのが目的のスレじゃねーんだから、
どっちにしてもこのスレで広がる話題ではないけどな
具体例に落とすには、まず何を求めるかを明確にする必要があるのに
それをやらずに答えてみろっていう問題が問題だっていう話
仕様を提案しながら固めるのが目的のスレじゃねーんだから、
どっちにしてもこのスレで広がる話題ではないけどな
あのアホ、ここがプログラマー板だって事忘れて、プログラマを貶める発言とかしてるからな。
それよりも例外の話しようぜ
人のフリみてなんとやら
何を根拠に〜っていうのは、数学的に0除算〜と思うけど、つー部分にも当てはまるけどな
あ、ソースはこれだ、とかいった話は別に続けなくていいよ。スレ違いだから
何を根拠に〜っていうのは、数学的に0除算〜と思うけど、つー部分にも当てはまるけどな
あ、ソースはこれだ、とかいった話は別に続けなくていいよ。スレ違いだから
たしかにな、「解なし」はもちろん例外でも無いしエラーですら無い。
通常の答えだ、このスレにはまったく関係ない。
まっ、問題を出した人間が中学生の数学も分からない
例外的人間だと言う事は分かるがｗ
通常の答えだ、このスレにはまったく関係ない。
まっ、問題を出した人間が中学生の数学も分からない
例外的人間だと言う事は分かるがｗ
517 ：仕様書無しさん：2011/02/28(月) 14:22:34.10
正しい例外の使い方をしめしてください
>>518
C言語と日本語でお願いします。
C言語と日本語でお願いします。
おいちょっとまて
521 ：仕様書無しさん：2011/03/01(火) 01:21:57.72
基本の使い方でなく、業務的に入り組んだサンプルがほしいです
コードだけ示されてもなぁ・・・
何をどうしたいために、どういう風に実装してるか、なぜ、それで
なければいけないか、とかの解説付きでないと意味ねーよ。
何をどうしたいために、どういう風に実装してるか、なぜ、それで
なければいけないか、とかの解説付きでないと意味ねーよ。
整数型や文字列へのポインタを返す例外をキャッチしたら、誰から
投げられたかが分かるんだｗ
どんな原因で起きたかが分かるんだｗｗｗ
投げられた整数値に、そういう事が分かる番号割り振ってるんだｗ
文字列に、そういう意味のトークン繋げてるんだｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
投げられたかが分かるんだｗ
どんな原因で起きたかが分かるんだｗｗｗ
投げられた整数値に、そういう事が分かる番号割り振ってるんだｗ
文字列に、そういう意味のトークン繋げてるんだｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
捕まえたとこで処理できない場合
ラップして上に投げるのはごく普通のこと
例外クラスでググれ
ラップして上に投げるのはごく普通のこと
例外クラスでググれ
そんな事言ってないだろ
>>525
> 整数型や文字列へのポインタを返す例外をキャッチしたら、誰から
> 投げられたかが分かるんだｗ
なんのために、誰から投げられてか
知りたいのかわかんないんだけど？
誰から投げられたかなんてどうでもよくね？
関数の中の誰かってだけわかれば
それで十分だと思うが？
> 整数型や文字列へのポインタを返す例外をキャッチしたら、誰から
> 投げられたかが分かるんだｗ
なんのために、誰から投げられてか
知りたいのかわかんないんだけど？
誰から投げられたかなんてどうでもよくね？
関数の中の誰かってだけわかれば
それで十分だと思うが？
func1();
func2();
func3();
のどれで例外が発生したかを区別する必要があることはよくあるな。
func2();
func3();
のどれで例外が発生したかを区別する必要があることはよくあるな。
そこで継承だろ
発生元の区別が必要ならcatch後の処理も違うんだから、まずtry-catch句を分けろよ
またそこへ戻るのかw
戻るも何も例外の思想を理解してないだけじゃん
戻るっていうか基本だわなｗ
理解してない奴は最初でtry最後でcatchしてそれで全てを知ってると思ってるけど
理解してない奴は最初でtry最後でcatchしてそれで全てを知ってると思ってるけど
無秩序に例外使いまくってるアホは黙ればいいのに。それ、オマエの都合
だけで書いてるから、他の誰も理解したがらないわ。
だけで書いてるから、他の誰も理解したがらないわ。
と、簡単な仕組みすら理解する能力のない馬鹿が無能を曝け出していましたとさ。
人に迷惑を掛けなければ、どんな例外処理をしてもいいと思うが
俺の職場には共通モジュールで、エラー処理を例外クラスにしている馬鹿がいる。
実行EXEでは構わないが、デバック中にエラーごとに例外が
IDEに飛んで来て実行が中断し、とても迷惑している。
本人は自慢げにエラーを例外で処理していると言っているが
単に技術や知識が乏しい迷惑な奴だ。
俺の職場には共通モジュールで、エラー処理を例外クラスにしている馬鹿がいる。
実行EXEでは構わないが、デバック中にエラーごとに例外が
IDEに飛んで来て実行が中断し、とても迷惑している。
本人は自慢げにエラーを例外で処理していると言っているが
単に技術や知識が乏しい迷惑な奴だ。
例えばこういうの？
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;
}
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;
}
継承を使えばいいだろ（ｷﾘｯ
上司に異常を報告しても、「なんとかしろ」と言われるだけ。
で、助教に応じて「なんとかする」という仮想メソッドを実行する。
だったら報告せずに、内々で「何とかする」方がマシ。
上司に異常を報告しても、「なんとかしろ」と言われるだけ。
で、助教に応じて「なんとかする」という仮想メソッドを実行する。
だったら報告せずに、内々で「何とかする」方がマシ。
× 助教
○ 状況
○ 状況
いきなりどうした
>>538
catchしてない例外ならバグじゃねーの
catchしてない例外ならバグじゃねーの
>>537
仕事では既に決まってる要求仕様は実現しないといけないからねぇ。
仕事では既に決まってる要求仕様は実現しないといけないからねぇ。
>>538
> 実行EXEでは構わないが、デバック中にエラーごとに例外が
> IDEに飛んで来て実行が中断し、とても迷惑している。
お前のほうが知識に乏しいんじゃね？
例外でIDEが中断しないように設定すれば済む話。
> 実行EXEでは構わないが、デバック中にエラーごとに例外が
> IDEに飛んで来て実行が中断し、とても迷惑している。
お前のほうが知識に乏しいんじゃね？
例外でIDEが中断しないように設定すれば済む話。
自分で解決できないからって
上司に相談するやつは無能。
それが許されるのは新人だけ。
上司に相談するやつは無能。
それが許されるのは新人だけ。
ホウレンソウ
まぁクサレ上司も多いからな。
上司クラスが腐ってるアプリケーションは稀に良くある
つぎはぎつぎはぎしてきたせいで今更改修するわけにもいかない状態で
アホみたいなことしないといけない、泥沼コース
そういや、んなとこだと、まともにtry-catchできてるようなのは一度も見たことねーなｗ
つぎはぎつぎはぎしてきたせいで今更改修するわけにもいかない状態で
アホみたいなことしないといけない、泥沼コース
そういや、んなとこだと、まともにtry-catchできてるようなのは一度も見たことねーなｗ
上司が腐ってれば、
何を使っても同じことだろうさ
ということでこの話題は終わり。
例外は素晴らしいね。
何を使っても同じことだろうさ
ということでこの話題は終わり。
例外は素晴らしいね。
>>543
>catchしてない例外ならバグじゃねーの
例外処理はしているが、その前にIDEが一度中断するから
たちが悪い。
>>545
>お前のほうが知識に乏しいんじゃね？
>例外でIDEが中断しないように設定すれば済む話。
お前みたいな中途半端な知識しかもってない人間が駄目なんだよな。
もちろん設定出来るものはしているが、出来ないケースもあるんだよ。
知識が無い奴は黙ってろよ。
>catchしてない例外ならバグじゃねーの
例外処理はしているが、その前にIDEが一度中断するから
たちが悪い。
>>545
>お前のほうが知識に乏しいんじゃね？
>例外でIDEが中断しないように設定すれば済む話。
お前みたいな中途半端な知識しかもってない人間が駄目なんだよな。
もちろん設定出来るものはしているが、出来ないケースもあるんだよ。
知識が無い奴は黙ってろよ。
> もちろん設定出来るものはしているが、出来ないケースもあるんだよ。
できないケースってなに？
IDEとできないケースを言ってみ。
できないケースってなに？
IDEとできないケースを言ってみ。
もう寝たのか？答えられないのか？
IDEで例外発生時に止めることができるのなら、
それをOFFにすることは簡単なはずで
それをサポートしてなんてあるはずないんだが。
IDEで例外発生時に止めることができるのなら、
それをOFFにすることは簡単なはずで
それをサポートしてなんてあるはずないんだが。
>>554
>できないケースってなに？
>IDEとできないケースを言ってみ。
そんなのも分からないのか？
知識も経験も無いんだな。
>>556
>それはIDEの設定が悪いだけじゃん
>VSだっけ？最近使ってないから忘れたけど
お前も、知識・経験が無いんだな。
ボクちゃんたち頑張って経験積もうね。
>できないケースってなに？
>IDEとできないケースを言ってみ。
そんなのも分からないのか？
知識も経験も無いんだな。
>>556
>それはIDEの設定が悪いだけじゃん
>VSだっけ？最近使ってないから忘れたけど
お前も、知識・経験が無いんだな。
ボクちゃんたち頑張って経験積もうね。
裸の王様はじまったな
ここまで絵に書いたようなテンプレ回答返すとか、また例の馬鹿が戻ってきたかｗ
例外の否定のときと同じで、答えれないから「知らないの？」って質問を質問で返すんだよな
例外の否定のときと同じで、答えれないから「知らないの？」って質問を質問で返すんだよな
IOExceptionとか滅多に起こらない障害の例外処理はめんどいでござる
例外じゃなくてエラーでいいのに
例外じゃなくてエラーでいいのに
>>560
検査例外なのが悪いだけで、例外は悪くないんじゃない？
検査例外なのが悪いだけで、例外は悪くないんじゃない？
563 ：仕様書無しさん：2011/03/03(木) 10:38:20.49
ここの例外馬鹿はエラーチェックはしないポリシーですから
564 ：仕様書無しさん：2011/03/03(木) 10:40:37.07
例外馬鹿の特徴
・設計関連の知識はゼロ
・例外は自分の書いたコードがうまくうごくまでのデバッグツールとして利用
(つまり、設計書からまたは頭で描いたコードをそのまま落として実行できない
すわなち、馬鹿)
・スクリプト言語しか使えない
(つまりコンパイルエラーとかは経験がないので、例外だけを語れるようになった)
・設計関連の知識はゼロ
・例外は自分の書いたコードがうまくうごくまでのデバッグツールとして利用
(つまり、設計書からまたは頭で描いたコードをそのまま落として実行できない
すわなち、馬鹿)
・スクリプト言語しか使えない
(つまりコンパイルエラーとかは経験がないので、例外だけを語れるようになった)
滅多に起こらないからこそ例外なのである
>>567
あぁ、「自分では」エラーチェックしないってことか。それはそうだな。
あぁ、「自分では」エラーチェックしないってことか。それはそうだな。
いや待て。例外を投げるときにはチェックするぞ。やっぱりおかしいな。
>>560は、いっそアプリが落ちていいよと言ってる気がするのは俺だけ？
エラー処理が面倒だからとか、滅多に起こらないからとか
誰かが何とかしてくれるだろう的な例外が一番嫌い
ずばり、設計に無い例外を投げるのはバグです
誰かが何とかしてくれるだろう的な例外が一番嫌い
ずばり、設計に無い例外を投げるのはバグです
>上司クラスが腐ってるアプリケーションは稀に良くある
稀に良くある・・・ どっちやねん(´・ω・`)
稀に良くある・・・ どっちやねん(´・ω・`)
もう何言っても言い負かされるから、「例外馬鹿め！」って喚き散らすしかできなくなった、
いつもの例外すら理解できない馬鹿がまた沸いてるなｗ
>>571
エラー処理が面倒だから無視されるより、処理してなかったら不具合がすぐそこで分かるほうがマシ
例外じゃなかった場合、その不正値が無視されてても誰もわからないままになって
そいつがとんでもないところでやらかして、データ全破壊とかするかも知れんしな
いつもの例外すら理解できない馬鹿がまた沸いてるなｗ
>>571
エラー処理が面倒だから無視されるより、処理してなかったら不具合がすぐそこで分かるほうがマシ
例外じゃなかった場合、その不正値が無視されてても誰もわからないままになって
そいつがとんでもないところでやらかして、データ全破壊とかするかも知れんしな
どっちかつーと設計も開発も糞な奴は例外なく「例外」を理解できてない、だわな。
いつものｒｙは、例外をデバッグツール()とか、また頭の悪いこと言ってるけど、
それは例外どころか、デバッガのアタッチすらできない正真正銘の無能が、
Alertデバッグの代わりに例外でブレークしてるつーアホ話だろ。
そんな使い方する馬鹿が例外を語れると思ってるあたり、相変わらず頭悪いな。
いつものｒｙは、例外をデバッグツール()とか、また頭の悪いこと言ってるけど、
それは例外どころか、デバッガのアタッチすらできない正真正銘の無能が、
Alertデバッグの代わりに例外でブレークしてるつーアホ話だろ。
そんな使い方する馬鹿が例外を語れると思ってるあたり、相変わらず頭悪いな。
>>574
お前、いつも人格否定しかできないじゃん
お前、いつも人格否定しかできないじゃん
図星だったらしい。
即レスするほど張り付いてんのか
製作者が不正だと思い込んだものに対してはやたらと厳しいのに
そもそも仕様書にはどう書いてあるんだよ？
っていうところがあいまいになるんだよなｗ
そもそも仕様書にはどう書いてあるんだよ？
っていうところがあいまいになるんだよなｗ
最下流工程にしかかかわらせてもらえないコーダーは悲しいねー
例外の場合エラーチェックをしないじゃなくて
デフォルトのエラーチェックに任せるって感じだよな。
戻り値の場合は、本当にエラーチェックをしないだから
だめなんだが。言うまでもなかろう。
デフォルトのエラーチェックに任せるって感じだよな。
戻り値の場合は、本当にエラーチェックをしないだから
だめなんだが。言うまでもなかろう。
検査例外万歳。
わりとマジ。
わりとマジ。
検査例外でよかったことなんてあるの？
try {
・・・
} catch(検査例外) {
同じコード
} catch(RuntimeExcepiton e) {
同じコード
}
結局こんなふうに重複コードを書いて終わりな気がするんだが？
try {
・・・
} catch(検査例外) {
同じコード
} catch(RuntimeExcepiton e) {
同じコード
}
結局こんなふうに重複コードを書いて終わりな気がするんだが？
そろそろ釣り宣言
>>583
検査例外じゃなくてもやるだろ
検査例外じゃなくてもやるだろ
>>586
やんねーよタリーな
やんねーよタリーな
例外ってチェックするもんじゃねーだろ
検査例外はプロジェクト全体がちゃんと正しく使ってるならヒューマンエラーの回避にはなる
ただし馬鹿が一人混じるだけで崩壊する
「コンパイル通らない！」
「そうか、意味はわからないけど throws Exception ってつければ問題ないのか」
こんなアホが現実に存在する不思議
ただし馬鹿が一人混じるだけで崩壊する
「コンパイル通らない！」
「そうか、意味はわからないけど throws Exception ってつければ問題ないのか」
こんなアホが現実に存在する不思議
つまり、例外は使い物にならないって事ですね。わかります。
アホがいないプロジェクトなら、戻り値でもやっていけるさ
結局アホが居ると何やってもダメという当たり障りのない結論に
同僚の顔がキモすぎて仕事に集中できない。
同性の顔なんて気にならねーって思ってたけど全然違うんだな
同性の顔なんて気にならねーって思ってたけど全然違うんだな
それは鏡だ
595 ：おじゃばさま：2011/03/05(土) 08:03:37.02
戻り値を否定するのか。
ケースによっては戻り値でswitch文の多重分岐を起動するトリガにするんだけどな
ここの例外馬鹿は多重分岐のトリガも例外でしょりするのかな
ケースによっては戻り値でswitch文の多重分岐を起動するトリガにするんだけどな
ここの例外馬鹿は多重分岐のトリガも例外でしょりするのかな
596 ：おじゃばさま：2011/03/05(土) 08:55:40.76
>デバッガのアタッチ
あんな素人しか使わない仕組みでデバッグしてるのか?
あんな素人しか使わない仕組みでデバッグしてるのか?
597 ：おじゃばさま：2011/03/05(土) 08:59:18.27
プロセスのアタッチ手法はIDEを二つ起動してPIDにアタッチしてデバッグするのだが
それりゃ、かったるい事このうえない。
問題が発生している箇所をダンプすれば一発でわかるのになあ。
つまり、例外馬鹿は「そもそもどこで不具合が発生したか」すらわからない馬鹿
それりゃ、かったるい事このうえない。
問題が発生している箇所をダンプすれば一発でわかるのになあ。
つまり、例外馬鹿は「そもそもどこで不具合が発生したか」すらわからない馬鹿
なんでIDEを二つ起動するんだ
>>595
なんでそんな曲解するの？
関数の戻り値に値とエラー値を混ぜるなって話。
たとえば、プラスだったら○○という意味で
マイナスならエラーとかいうふうに混ぜるなということ。
エラー値を混ぜるところは、例外でやれという話。
なんでそんな曲解するの？
関数の戻り値に値とエラー値を混ぜるなって話。
たとえば、プラスだったら○○という意味で
マイナスならエラーとかいうふうに混ぜるなということ。
エラー値を混ぜるところは、例外でやれという話。
> 問題が発生している箇所をダンプすれば一発でわかるのになあ。
問題が発生ている箇所をダンプしなくても
一発でわかるのが例外。
問題が発生ている箇所をダンプしなくても
一発でわかるのが例外。
601 ：おじゃばさま：2011/03/05(土) 09:54:24.05
>>599
君は経験がないようだね。多重分岐するための値とエラー値と混ざるよ
それは当然でしょう。多重分岐処理判断のメソッドで例外捕獲したとしても
リターンした上位のcaseでdefaulでエラー処理する必要があるだろう
正常値とエラー値とまざるときはまざらざるをえないんだよ。馬鹿だな
これらはサーバ系の開発の話だけどね、クライアントスクリプト言語糞アプリは
エラーが起こってもスクリプト例外で画面表示されるだけだからべつにどうでも
いいかもしれんがね
君は経験がないようだね。多重分岐するための値とエラー値と混ざるよ
それは当然でしょう。多重分岐処理判断のメソッドで例外捕獲したとしても
リターンした上位のcaseでdefaulでエラー処理する必要があるだろう
正常値とエラー値とまざるときはまざらざるをえないんだよ。馬鹿だな
これらはサーバ系の開発の話だけどね、クライアントスクリプト言語糞アプリは
エラーが起こってもスクリプト例外で画面表示されるだけだからべつにどうでも
いいかもしれんがね
>>601
日本語で頼む
日本語で頼む
俺は成功失敗のある関数の戻り値は可能な限りbool派
せめてちょっとは文体を似せる努力ぐらいしろよ…
605 ：おじゃばさま：2011/03/05(土) 10:23:38.22
>>603
BOOLですべてこと足りればそれでいいと思うが
たとえばファイルを読み込んでクラアントブラウザにコンテンツを送信する
HTTPサーバだと、読み込んだファイルのサイズをContent-Length:にセットしなければ
ならない。BOOLの場合だと if (FALSE) content_len = 0;
とか上位でコンテントレングスのエラー時のコントロールが必要になってしまう
BOOLですべてこと足りればそれでいいと思うが
たとえばファイルを読み込んでクラアントブラウザにコンテンツを送信する
HTTPサーバだと、読み込んだファイルのサイズをContent-Length:にセットしなければ
ならない。BOOLの場合だと if (FALSE) content_len = 0;
とか上位でコンテントレングスのエラー時のコントロールが必要になってしまう
606 ：おじゃばさま：2011/03/05(土) 10:28:48.20
608 ：おじゃばさま：2011/03/05(土) 10:31:06.08
>>607
それとかあれとかナニがでは「コードレビューもできんやつだな」と烙印をおされるぞ
それとかあれとかナニがでは「コードレビューもできんやつだな」と烙印をおされるぞ
610 ：おじゃばさま：2011/03/05(土) 11:19:18.77
>>609って本当に馬鹿がヅラーと連なったようなやつだね
埋め込みの500番のエラーページもブラウザに表示される分のContent-Lengthが
セットされているんだよ。内部的に読み込めない->エラー->content_len=0
をたとえばエラーの判断として HTTPヘッダをつくり、エラー表示分のコンテントレングス
をヘッダにのせるんだよ。もっと深いとこまで考えてみろよ。むりか、所詮ブラウザで
動作するスクリプターだからなあ
埋め込みの500番のエラーページもブラウザに表示される分のContent-Lengthが
セットされているんだよ。内部的に読み込めない->エラー->content_len=0
をたとえばエラーの判断として HTTPヘッダをつくり、エラー表示分のコンテントレングス
をヘッダにのせるんだよ。もっと深いとこまで考えてみろよ。むりか、所詮ブラウザで
動作するスクリプターだからなあ
そうなんだよね。
エラーが起きたとき、そのエラーが起きた情報ってのが必要になる。
その情報は値の集合体だからboolやintじゃ足りない。
じゃあ構造体を使う。どんな場合でも同じやり方が出来るように
引数で値を返す。とかいう決まりを作っていったら
そこでふと考えるべきなんだ。
そうやって考えて作ったものが、例外なんだと。
エラーが起きたとき、そのエラーが起きた情報ってのが必要になる。
その情報は値の集合体だからboolやintじゃ足りない。
じゃあ構造体を使う。どんな場合でも同じやり方が出来るように
引数で値を返す。とかいう決まりを作っていったら
そこでふと考えるべきなんだ。
そうやって考えて作ったものが、例外なんだと。
612 ：仕様書無しさん：2011/03/05(土) 11:34:15.47
エラー内容を１ファイルのログからすべて推測できるようにするべきだろうな
614 ：おじゃばさま：2011/03/05(土) 11:42:28.55
もう馬鹿==>>609の反論はないのか、情けないやつだな
615 ：おじゃばさま：2011/03/05(土) 11:43:54.63
まあ、所詮例外例外って騒ぐ馬鹿は正常系のインプリメントもまともに
できないから騒いでいるだけなんだろうな
できないから騒いでいるだけなんだろうな
それ、逆だと思うよｗ
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); .....
戻り値のエラー情報を構造体を使って共通化する例を考えてみた
よければ添削してくれないか
どんなデータタイプでも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 それとかあれとかどれとか言うやつはこの業界ではクズな定説
620 ：おじゃばさま：2011/03/05(土) 12:21:04.48
> ただし明示的なキャストが必要になるのでこれもサーバ系開発向きかな
意味がわからんｗ
意味がわからんｗ
622 ：おじゃばさま：2011/03/05(土) 12:23:28.99
プロトタイプはこのほうがいいかも、まあ構造体のコピーでもいいけど
無駄だよな、参照のほうが合理的だと思う
ERR_STAT* hoge(void);
ERR_STAT* hoge(int); .....
無駄だよな、参照のほうが合理的だと思う
ERR_STAT* hoge(void);
ERR_STAT* hoge(int); .....
>>620
> バッファオーバーフローやアドレスセットはコーディングするプログラマの責任範囲
> だから「間違えないでインプリメントする」が基本
間違えたときにその原因がすぐに分かるようにするのも
プログラマの責任の範囲だよ。
> ここはあえて>>619がしてみてくれないか?
例外を使えばできるけど、
例外を使わないなら無理。
> バッファオーバーフローやアドレスセットはコーディングするプログラマの責任範囲
> だから「間違えないでインプリメントする」が基本
間違えたときにその原因がすぐに分かるようにするのも
プログラマの責任の範囲だよ。
> ここはあえて>>619がしてみてくれないか?
例外を使えばできるけど、
例外を使わないなら無理。
624 ：おじゃばさま：2011/03/05(土) 12:24:14.78
>>610
言語によるが、例えば静的に存在する文字列を
acceptしたTCPソケットに直接writeすりゃ良い。
要は最悪ケースのエラーページは下位層に
ハードコーディングしときゃ良いんだよ。
何で上位がそんなモンを設定する必要がある。
言語によるが、例えば静的に存在する文字列を
acceptしたTCPソケットに直接writeすりゃ良い。
要は最悪ケースのエラーページは下位層に
ハードコーディングしときゃ良いんだよ。
何で上位がそんなモンを設定する必要がある。
ダウンキャストとアップキャストの違い知ってる？
void*を使うのは危険だよね。
void*を使うのは危険だよね。
628 ：おじゃばさま：2011/03/05(土) 12:28:12.55
つうか、仕様どおりの実装をしたとき、おのずとエラーの種別
エラー内容を表示するためのデータ型とか固定になると思うのだが?
だから「原因」などわからなくともインプリメントを間違えばコードを書いている
ときにすぐ分かることだと思うけど。
間違えたときの原因なんて例外を使わなくともわかるだろう?
お前さんキングオブ馬鹿だな
エラー内容を表示するためのデータ型とか固定になると思うのだが?
だから「原因」などわからなくともインプリメントを間違えばコードを書いている
ときにすぐ分かることだと思うけど。
間違えたときの原因なんて例外を使わなくともわかるだろう?
お前さんキングオブ馬鹿だな
> 間違えたときの原因なんて例外を使わなくともわかるだろう?
わかるかわからないかの話をしてるんじゃないよ。
わかるまでにかかる時間の話。
例外を使っていれば、エラーが出たらすぐに分かる。
原因となった関数とか行番号とかも表示されるから。
わかるかわからないかの話をしてるんじゃないよ。
わかるまでにかかる時間の話。
例外を使っていれば、エラーが出たらすぐに分かる。
原因となった関数とか行番号とかも表示されるから。
630 ：おじゃばさま：2011/03/05(土) 12:33:13.60
>>627
キングオブ馬鹿さん、それはオブジェクトのキャストだろ
参照のアドレスをセットするだけだから、コンパイラにはデータの
sizeofを知らせてやる必要のあるキャストだ
ポインタアドレスはsizeofプロセッサ固定だからな
キングオブ馬鹿さん、それはオブジェクトのキャストだろ
参照のアドレスをセットするだけだから、コンパイラにはデータの
sizeofを知らせてやる必要のあるキャストだ
ポインタアドレスはsizeofプロセッサ固定だからな
631 ：おじゃばさま：2011/03/05(土) 12:34:35.59
>>629
だから >>628で言っているように、そんなくだらない間違いは即わかるのが
職業プログラマだろ、お前の言っているのは「素人がコードが書けないから
例外でデバッグを支援してもらいたい」としか聞こえん
だから >>628で言っているように、そんなくだらない間違いは即わかるのが
職業プログラマだろ、お前の言っているのは「素人がコードが書けないから
例外でデバッグを支援してもらいたい」としか聞こえん
どうも例外を使わないやつって、
発想がプログラムを作ってるだけな気がするな。
自分が今担当しているプログラムだけが動けばそれでいい感じ
例外を使う人って、プログラム単体だけではなく
プログラムを使って構成されたシステム全体が
統一された方法で正しく動くってことまで考えてる。
だから、どちらが安全かとかどちらが開発効率がいいかとか
どちらが汎用的に使える仕組みであるかとか設計とか
そういう高レベルなところから物事を見てる。
考えてる範囲が大きく違いすぎるよね。
発想がプログラムを作ってるだけな気がするな。
自分が今担当しているプログラムだけが動けばそれでいい感じ
例外を使う人って、プログラム単体だけではなく
プログラムを使って構成されたシステム全体が
統一された方法で正しく動くってことまで考えてる。
だから、どちらが安全かとかどちらが開発効率がいいかとか
どちらが汎用的に使える仕組みであるかとか設計とか
そういう高レベルなところから物事を見てる。
考えてる範囲が大きく違いすぎるよね。
>>631
例外でデバッグを支援してもらうって発想が
お前が例外に使われてるだけのやつだって示してるよ。
例外はな道具だ。俺が例外を使って
開発を楽にするようにコーディングするんだよ。
開発を楽にするための道具はなんでも使うよ。
例外でもデバッガでもユニットテストでも。
でもお前は、それらを使ったら
コードを書けないから道具を使うんだろと言うんだろ？
アホじゃね？
例外でデバッグを支援してもらうって発想が
お前が例外に使われてるだけのやつだって示してるよ。
例外はな道具だ。俺が例外を使って
開発を楽にするようにコーディングするんだよ。
開発を楽にするための道具はなんでも使うよ。
例外でもデバッガでもユニットテストでも。
でもお前は、それらを使ったら
コードを書けないから道具を使うんだろと言うんだろ？
アホじゃね？
634 ：おじゃばさま：2011/03/05(土) 12:56:02.34
話すこと（反論）がないなら、レスしなければいいじゃんｗ
636 ：仕様書無しさん：2011/03/05(土) 14:12:02.01
いやいや、仕様が全く理解できない馬鹿にいくらナニをいっても無駄ということ
おじゃばはスレの流れイマイチ分かってないのか知らんけど
大抵は、例外否定派は全部の例外をなくせ、一切例外は発生させるな、戻り値で返せって主張してて
例外肯定派は、戻り値では出来ないことでも出来るしケースによるだろって感じだぞ
処理しきれない状況になって例外が発生した場合に、
エラーを示す値を戻り値で返す場合、
意図しないエラー無視が出来てしまうから、極力控えるべきだと思うよ
例外を投げるのは、異常系とかの考慮が足りてない人に向けた対策みたいなもんだしな
大抵は、例外否定派は全部の例外をなくせ、一切例外は発生させるな、戻り値で返せって主張してて
例外肯定派は、戻り値では出来ないことでも出来るしケースによるだろって感じだぞ
処理しきれない状況になって例外が発生した場合に、
エラーを示す値を戻り値で返す場合、
意図しないエラー無視が出来てしまうから、極力控えるべきだと思うよ
例外を投げるのは、異常系とかの考慮が足りてない人に向けた対策みたいなもんだしな
>>631
職業マは、仕事以上の勉強は絶対にしないし、仕事中しかコーディングしないし、
行き当たりばったりでスパゲッティな打開策を積み重ねるような奴のことだぞ。
おじゃばさまってのがなんなのかは俺は知らんが、見てるとなんかいろいろ勘違いしてそう。
空気は読めないけど、適当な敵を作って議論もどきをするのが趣味な人なん？
職業マは、仕事以上の勉強は絶対にしないし、仕事中しかコーディングしないし、
行き当たりばったりでスパゲッティな打開策を積み重ねるような奴のことだぞ。
おじゃばさまってのがなんなのかは俺は知らんが、見てるとなんかいろいろ勘違いしてそう。
空気は読めないけど、適当な敵を作って議論もどきをするのが趣味な人なん？
話はすごく単純で
戻り値に、二種類の違った値を入れるなというだけのこと。
変数に二種類の違った値を入れたら
どうなるかぐらいわかるだろう。
戻り値に、二種類の違った値を入れるなというだけのこと。
変数に二種類の違った値を入れたら
どうなるかぐらいわかるだろう。
自分でいろんな言語を使おうという人なら、
例外がある言語を使ったことはあるはず。
COBOLとC以外でメジャーな言語なら
例外あるからね。
例外がある言語を使ったことはあるはず。
COBOLとC以外でメジャーな言語なら
例外あるからね。
>>638
今いるのは、偽おじゃばだよ。
今いるのは、偽おじゃばだよ。
>>642
あれ、いくらなんでもアホ過ぎるとはおもったけど、いつものアホだったってオチ？
あれ、いくらなんでもアホ過ぎるとはおもったけど、いつものアホだったってオチ？
ああ本当だ。全然違うわｗ
どっちでもいいが、いつもアホ過ぎぐらいのアホだよ。あいつは。
あ、もちろん例外使うなーって叫んでる何時ものアホのことです。
647 ：おじゃばさま：2011/03/05(土) 14:50:47.49
苦しいな
なら病院行け
いろいろ言われてるのに、スレと関係ないどうでもいいところにしかレス返せない時点で
ホンモノはもっとこうムカツキ感が高い。まわりくどい感じとか。
思わずこの野郎、と突っ込みたくなる不快さに欠けるねニセモノは。
バカをするにも芸がないとダメだという見本。
思わずこの野郎、と突っ込みたくなる不快さに欠けるねニセモノは。
バカをするにも芸がないとダメだという見本。
素で馬鹿な奴はこんなもんが限界だろうな。
残念ながらおじゃばは素で馬鹿
>>639
例外とは関係ないけどね。
例外とは関係ないけどね。
このコテってここまで馬鹿だったっけ？
発言もキレがないし前より劣化してないか？
発言もキレがないし前より劣化してないか？
別な意味でバカさが足りない。もっとこうネチネチしてないと。
言葉尻捉えてるだけのアホだから、テキトーにからかってやればすぐにボロを出すのに？
>>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であることを高らかに宣言し、例外をスローしなければならない。
要するに仕様にあるべきなのが戻り値で、あってはならないのが例外。
仕様や設計が決められないここの連中にはレベルが高すぎて一生ついてこれないだろうけどな。
そもそも、お前らが設計をやること自体がソフトウェア工学に対する冒涜にも値するわけで……
戻り値はエラーを返すためにあるものじゃない。
あくまでも仕様上定められた値を返すためにある。そこを理解していないと積むので注意。
素人にはこれが分からない。
仕様上返すべき値であれば、それが何であれ戻り値にすべきだが例えば、
ojava(object o) {
// oにnullが入ってきた。
}
という状況で仕様上oは非nullであると定められていたのならば、
ojava( object o {
if (o == null) {
NullZamasuwayoException("o");
}
}
とでもやって、oがnullであることを高らかに宣言し、例外をスローしなければならない。
要するに仕様にあるべきなのが戻り値で、あってはならないのが例外。
仕様や設計が決められないここの連中にはレベルが高すぎて一生ついてこれないだろうけどな。
そもそも、お前らが設計をやること自体がソフトウェア工学に対する冒涜にも値するわけで……
おや、本物のおじゃばが出てきたｗ
戻り値厨の偽おじゃばどうするよｗ
戻り値厨の偽おじゃばどうするよｗ
つまらん自演。そーゆーとこがニセモノはなんというか軽いな。
ホンモノは堂々と自信を持ってバカだぞ。そんな小賢しい学習能力などない。
ホンモノは堂々と自信を持ってバカだぞ。そんな小賢しい学習能力などない。
662 ：おじゃばさま：2011/03/06(日) 08:26:36.83
うはうは
663 ：仕様書無しさん：2011/03/06(日) 13:42:59.54
例外を使いこなせないというよりは
例外ハンドラの奴隷というほうが正しいと思うが
ものによってtyrブロックで囲まないとコンパイルエラーになるしな
例外ハンドラの奴隷というほうが正しいと思うが
ものによってtyrブロックで囲まないとコンパイルエラーになるしな
理解できないお馬鹿さんには翻弄されてる気分になるのか
ただの言語機能の一つでしかないのにな
ただの言語機能の一つでしかないのにな
翻弄されていることに気づかないのも問題だけどな。
流石にだいぶ落ち着いてきたな。
いつもの例外全否定のアホも、最近は叩かれないようにって、
どっちつかずな感じの短文レスばっかりになったし、
例外自体は普通の仕組みだから、今更これといって広がるような話題もないしで、
当たり前っちゃ当たり前だろうけど、一時期の勢いが嘘のようだ…(ｗ
いつもの例外全否定のアホも、最近は叩かれないようにって、
どっちつかずな感じの短文レスばっかりになったし、
例外自体は普通の仕組みだから、今更これといって広がるような話題もないしで、
当たり前っちゃ当たり前だろうけど、一時期の勢いが嘘のようだ…(ｗ
一時期の勢いは、
例外を理解出来ないバカのせいだ。
たぶんプログラムの世界において
できると自信があったのだろう。
だが井の中の蛙であったことを知って
逆上したのだろう。
例外を理解出来ないバカのせいだ。
たぶんプログラムの世界において
できると自信があったのだろう。
だが井の中の蛙であったことを知って
逆上したのだろう。
つまらん自演。
↑もうこんなのばっかりになってきたねｗ
671 ：おじゃばさま：2011/03/07(月) 02:14:25.50
いやね、ちょっと忙しくなっちゃったんだよ
暇になったら、例外の内部コードをさらして、叩ききってあげるから
待っててね
暇になったら、例外の内部コードをさらして、叩ききってあげるから
待っててね
例外を全否定してるヤツなんていたか？
いねーよ。どっちのバカも自演だし。
なんか例外厨の粘り勝ちみたいになってきたな。
正論を書いても奴も基地外にはかなわないか。
これがネットだけじゃなく現実の世界でも
基地外みたいに声が大きい方が正しいとかなるから怖いよな。
正論を書いても奴も基地外にはかなわないか。
これがネットだけじゃなく現実の世界でも
基地外みたいに声が大きい方が正しいとかなるから怖いよな。
ここは、
例外を理解できなかったせいで、方々からフルボッコにされたおっさんが
どうにかして自分を叩いてた奴が悪いような雰囲気になるよう
試行錯誤しながら誘導を試みるためのスレッドになりました
もうそれくらいしかできることがないのです。いじめないであげてください(うω；`)
例外を理解できなかったせいで、方々からフルボッコにされたおっさんが
どうにかして自分を叩いてた奴が悪いような雰囲気になるよう
試行錯誤しながら誘導を試みるためのスレッドになりました
もうそれくらいしかできることがないのです。いじめないであげてください(うω；`)
え、なに？ 俺が例外厨煽らないといけない雰囲気なの？ なの？
テンパるのは結構だがせめて日本語を書け
うゎ〜、俺にも絡んできたｗ
あんたが正しいよ、確かに誤記があるね。
でも相手に「せめて日本語を書け」と書くなら、せめて句読点は書こうねｗ
あんたが正しいよ、確かに誤記があるね。
でも相手に「せめて日本語を書け」と書くなら、せめて句読点は書こうねｗ
いつもの厨レッテル張りご苦労さまです。
理解力のなさを叩かれて躍起になっちゃったんだね。
理解力のなさを叩かれて躍起になっちゃったんだね。
すぐに話題が脱線するアホが何言ってんだか
脱線つかこのスレいつ本筋?やってたんだw
馬鹿に使わせることが前提なら、ライブラリやら部品やらはとにかく他がcatchしない例外
javaなら検査例外にもかからない非チェック例外のサブクラスに詰めて投げて、
馬鹿に触らせないベースクラスでまとめて処理して、
極力馬鹿に例外を触らせないようにするのが、一番安全だと思う
それでもぬるぽやparse失敗での例外を無視してはバグを作りこむのだけれど
//こういう狭い範囲においては、検査例外は便利だｗ
javaなら検査例外にもかからない非チェック例外のサブクラスに詰めて投げて、
馬鹿に触らせないベースクラスでまとめて処理して、
極力馬鹿に例外を触らせないようにするのが、一番安全だと思う
それでもぬるぽやparse失敗での例外を無視してはバグを作りこむのだけれど
//こういう狭い範囲においては、検査例外は便利だｗ
馬鹿の定義が、プログラムをめちゃくちゃにする人なので
どんな方法を使ったところで、めちゃくちゃにする。
つまり、馬鹿を想定するのは意味が無い。
はい、馬鹿が使うと言う前提は無視しましょーｗ
やっぱり、例外のほうがいいんじゃね？
ちゃんと使えば（当たり前のこと）
戻り値よりも便利でしょ。
どんな方法を使ったところで、めちゃくちゃにする。
つまり、馬鹿を想定するのは意味が無い。
はい、馬鹿が使うと言う前提は無視しましょーｗ
やっぱり、例外のほうがいいんじゃね？
ちゃんと使えば（当たり前のこと）
戻り値よりも便利でしょ。
例外を使わせないGoogleはクソって話は、何スレ目くらいに出てる？
エラーをバケツリレーするっていう発想は、例外的な発想だな。
馬鹿を想定する意味がないって、このスレタイなのにかｗ
>>686
>エラーのバケツリレーなんて、最後までバケツが運ばれてくるかも怪しいし、
多相型推論を備えた関数型言語の場合、一般に値のバケツリレーは保証される。
これは直和型と呼ばれる厳格で階層的なデータ型定義が実現できていることによるもの。
（具体的には、Haskellなら newtype宣言、Standard MLならば datatype宣言と呼ばれる。）
たとえばStandard MLの場合、もしもバケツリレーの途中でコードに検査漏れがあれば、
コンパイル時にワーニングとして報告されるので、容易にミスを修正できる。
ワーニングを無視して実行させることは可能だけど、
その場合に漏れがあるケースを実行すると実行時エラーとなる。
>そもそもバケツ変わったら全修正とかアホすぎることはやりたくはないわｗ
Standard MLの場合、(クラスというOO概念は無いけど)抽象データ型をモジュール定義できるので、
バケツが変わった場合でもコード修正箇所を特定モジュールに限定させることも可能。
ただし、これらの厳格な型システムにも「抜け道」があって、その一つが例外。
（他の抜け道には、参照型による破壊的代入など。）
だから、規模の大きな開発になると、モジュール内部の関数間では便利な例外を使う事もあるけど、
モジュール間インターフェイスではいわゆる「バケツリレー」でエラーを渡すのが原則になる。
このスレ、手続き型言語限定ではないと思うので、参考まで。
>エラーのバケツリレーなんて、最後までバケツが運ばれてくるかも怪しいし、
多相型推論を備えた関数型言語の場合、一般に値のバケツリレーは保証される。
これは直和型と呼ばれる厳格で階層的なデータ型定義が実現できていることによるもの。
（具体的には、Haskellなら newtype宣言、Standard MLならば datatype宣言と呼ばれる。）
たとえばStandard MLの場合、もしもバケツリレーの途中でコードに検査漏れがあれば、
コンパイル時にワーニングとして報告されるので、容易にミスを修正できる。
ワーニングを無視して実行させることは可能だけど、
その場合に漏れがあるケースを実行すると実行時エラーとなる。
>そもそもバケツ変わったら全修正とかアホすぎることはやりたくはないわｗ
Standard MLの場合、(クラスというOO概念は無いけど)抽象データ型をモジュール定義できるので、
バケツが変わった場合でもコード修正箇所を特定モジュールに限定させることも可能。
ただし、これらの厳格な型システムにも「抜け道」があって、その一つが例外。
（他の抜け道には、参照型による破壊的代入など。）
だから、規模の大きな開発になると、モジュール内部の関数間では便利な例外を使う事もあるけど、
モジュール間インターフェイスではいわゆる「バケツリレー」でエラーを渡すのが原則になる。
このスレ、手続き型言語限定ではないと思うので、参考まで。
ミソもクソも一緒くたにして議論する意味を無くしてしまうのが、例外厨のいつもの戦術。
言語によってはサポートがあるつっても、大抵の人にゃ縁のない言語だけどな
汎用性の無い言語独自の機能よりも
厳格なコーディングルールが必要だろう
厳格なコーディングルールが必要だろう
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
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
ふざけんな男の娘はどこだよ！
現在都内で起こっている輪番停電の情報や電車の運行情報なのどがwebでの情報の取得が難しい形になっています。
そこでアンドロイドやiOSなのどのアプリでみんなで修正できるデータベース型のアプリを作成したい思ったのですが
すいません、自分は都内の工業大学に通っているものなんですがなにぶん頭が悪いもので発案しかできません
どなたか一緒にデータベースがたアンドロイド携帯やiOS向けのアプリを作成してくれる学生の方いらっしゃいませんか？
twitterだけだとどうにも運行情報がわかりにくいです。みんなで編集できるような簡単なデータベース型のアプリを作成するだけでも
できないでしょうか？
暇なを持て余している学生で構いません。協力してもらえませんか？ Mail: bbun■hotmail.co.jp ■＝@
そこでアンドロイドやiOSなのどのアプリでみんなで修正できるデータベース型のアプリを作成したい思ったのですが
すいません、自分は都内の工業大学に通っているものなんですがなにぶん頭が悪いもので発案しかできません
どなたか一緒にデータベースがたアンドロイド携帯やiOS向けのアプリを作成してくれる学生の方いらっしゃいませんか？
twitterだけだとどうにも運行情報がわかりにくいです。みんなで編集できるような簡単なデータベース型のアプリを作成するだけでも
できないでしょうか？
暇なを持て余している学生で構いません。協力してもらえませんか？ Mail: bbun■hotmail.co.jp ■＝@
俺が不便だから作れ、俺の手柄にする
>>698
別に仕組みはそんなに難しくないが、問題はインフラと見せ方な。
どれだけの人数を見積もってんのか知らんが、
ある程度の負荷に耐えられるだけの鯖が当然いる。
んで、見せ方な。Wiki程度ならそこらに無料のあるんだし、それ使えばいい。
運行情報が見辛いなら、どういった見せ方が効果的か案はあるのか。
また、誰もが編集できるというなら、知識のないものでも簡単にできるようにしなければならん。どうする。
ここまで絵を書いたら、始めて技術屋に可能かどうか聞いた方がいい。
発案つーか、そういうのはせめて企画書の一枚も書いてから言え。
まぁはてなあたりで言えば、暇人が「Rubyで書いてみた」とかいるかもしれんが。
別に仕組みはそんなに難しくないが、問題はインフラと見せ方な。
どれだけの人数を見積もってんのか知らんが、
ある程度の負荷に耐えられるだけの鯖が当然いる。
んで、見せ方な。Wiki程度ならそこらに無料のあるんだし、それ使えばいい。
運行情報が見辛いなら、どういった見せ方が効果的か案はあるのか。
また、誰もが編集できるというなら、知識のないものでも簡単にできるようにしなければならん。どうする。
ここまで絵を書いたら、始めて技術屋に可能かどうか聞いた方がいい。
発案つーか、そういうのはせめて企画書の一枚も書いてから言え。
まぁはてなあたりで言えば、暇人が「Rubyで書いてみた」とかいるかもしれんが。
>>698
http://teideninfo.tepco.co.jp/flash/index-j.html
これで駄目なのか？
スマートフォン用はないがhtml・Flashと携帯版があるが。
電車はないが。
http://teideninfo.tepco.co.jp/flash/index-j.html
これで駄目なのか？
スマートフォン用はないがhtml・Flashと携帯版があるが。
電車はないが。
>>701
2chで一番もっともな返信でした。
企画書の一枚・・・・・なるほど、すごくあたりまえなことに気づきませんでした・・・
すこし書いてみてほかのところで呼びかけてみます。
こんな未熟なレスに返信をくれてありがとうございます。
2chで一番もっともな返信でした。
企画書の一枚・・・・・なるほど、すごくあたりまえなことに気づきませんでした・・・
すこし書いてみてほかのところで呼びかけてみます。
こんな未熟なレスに返信をくれてありがとうございます。
放射線量計測サイト radio.2ch.net を作ろう
http://dso.2ch.net/test/read.cgi/sakhalin/1300188770/
http://dso.2ch.net/test/read.cgi/sakhalin/1300188770/
みんなでカキコならwikiでいいじゃんｗ
>>659
カスだな。
RuntimeErorrを自作すんなよ。
それからお前を、例外をデバッグ
ツールだと思ってるだろ。
例外はあくまでifと同じプログラムが
正常に動いてる事を前提とした制御機構だ。
javaと.netの様にデバッグ用に使えるのは少数派。
もともとコンストラクタとオペレーターの
オーバーロードで外部リソースなんかを確保できず戻り値を
返せない場合のために用意されたもんだ。
下らないことを吐くな。
カスだな。
RuntimeErorrを自作すんなよ。
それからお前を、例外をデバッグ
ツールだと思ってるだろ。
例外はあくまでifと同じプログラムが
正常に動いてる事を前提とした制御機構だ。
javaと.netの様にデバッグ用に使えるのは少数派。
もともとコンストラクタとオペレーターの
オーバーロードで外部リソースなんかを確保できず戻り値を
返せない場合のために用意されたもんだ。
下らないことを吐くな。
使えなくはないけど、ブレーク置けば済む話だから普通は使わないわな
それ以外の手段を実行できない人の苦肉の策だろうから、バカだなぁって思うけど、否定はしないでおこう
それ以外の手段を実行できない人の苦肉の策だろうから、バカだなぁって思うけど、否定はしないでおこう
>>708
いや、ブレーク使うには一旦コードを再実行しないといけないだろ？
例外は、デバックのために設置するのではなく、
普通の設計、普通のコーディングで普通に使う物。
そのなかで「ブレーク置きたい事態」になったとき
例外はすでに使われてるから、ブレーク置くまでもなく
状況が把握できる。
それに例外を使っておけば、例外をブレークの条件とすることもできる。
コードのあちこちにすでにブレークが仕込まれてると考えればいいよ。
そして例外をデバッグログに出力するようにしておけば・・・
そう考えると、コード中にバグを解析するためのコードが
たくさん埋めこまれていることになってるんだ。
想像してみ。コードのあちこちにバグ検出ポイントがある所を。
いや、ブレーク使うには一旦コードを再実行しないといけないだろ？
例外は、デバックのために設置するのではなく、
普通の設計、普通のコーディングで普通に使う物。
そのなかで「ブレーク置きたい事態」になったとき
例外はすでに使われてるから、ブレーク置くまでもなく
状況が把握できる。
それに例外を使っておけば、例外をブレークの条件とすることもできる。
コードのあちこちにすでにブレークが仕込まれてると考えればいいよ。
そして例外をデバッグログに出力するようにしておけば・・・
そう考えると、コード中にバグを解析するためのコードが
たくさん埋めこまれていることになってるんだ。
想像してみ。コードのあちこちにバグ検出ポイントがある所を。
> いや、ブレーク使うには一旦コードを再実行しないといけないだろ？
コードを再実行しないといけないという意味は、
バグがあると想定してない箇所で問題が起きたとき、
そこにブレークポイントを予め仕掛けておくことは不可能だから
再度実行しないといけないという意味。
例外は想定外のことが起きたら、すべて捕まえるように
作るのが正しいやり方だから、正しく使っている限り
想定外の動作を記録できる。
コードを再実行しないといけないという意味は、
バグがあると想定してない箇所で問題が起きたとき、
そこにブレークポイントを予め仕掛けておくことは不可能だから
再度実行しないといけないという意味。
例外は想定外のことが起きたら、すべて捕まえるように
作るのが正しいやり方だから、正しく使っている限り
想定外の動作を記録できる。
>>709
言いたい事は理解した
理解したが、それはバグ発見に繋がるけれど、デバッグのために使うわけではないな
printfを引き合いに出してるので、そのために例外を突っ込んでブレークする意味だって読み取れる
目的と用途の違い
例外はあくまでも、想定している処理が完遂できなかったことを示す、戻り値の一種みたいなもの
デバッグにも使えるっていう表現は、やっぱ、ちょっと語弊あると思う
言いたい事は理解した
理解したが、それはバグ発見に繋がるけれど、デバッグのために使うわけではないな
printfを引き合いに出してるので、そのために例外を突っ込んでブレークする意味だって読み取れる
目的と用途の違い
例外はあくまでも、想定している処理が完遂できなかったことを示す、戻り値の一種みたいなもの
デバッグにも使えるっていう表現は、やっぱ、ちょっと語弊あると思う
追記。706がバカだって思ってる部分に関しては否定してないからな
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句を見てしまうと、
強いストレス性の障害を起こして、胸が重苦しくなったり、
不眠症や拒食症・性機能障害などをを併発しちゃったりするものですから、時々使うのを躊躇してしまいます。
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句を見てしまうと、
強いストレス性の障害を起こして、胸が重苦しくなったり、
不眠症や拒食症・性機能障害などをを併発しちゃったりするものですから、時々使うのを躊躇してしまいます。
マジックナンバーって今日び新人でも使わないわ
>>709
きみの言うデバッグって何?
まさか単体テストでわかるnullポとかオーバーランの類いじゃないよね。
引数の間違いなら契約プログラミングで済む話だし...。
きっと演算結果がおかしかった時の事を言ってるんだよねっ、ねっ。
きみの言うデバッグって何?
まさか単体テストでわかるnullポとかオーバーランの類いじゃないよね。
引数の間違いなら契約プログラミングで済む話だし...。
きっと演算結果がおかしかった時の事を言ってるんだよねっ、ねっ。
例外はあらかじめ定義されていなければならないからね。
俺「君、単体テストは終わったかね？」
君「はい、単体テストの結果動かなかった所が10箇所ありました」
俺「バグが10個か。それでデバッグはいつ終わる？」
君「いえ、デバッグはしません」
俺「？」
君「はい、単体テストの結果動かなかった所が10箇所ありました」
俺「バグが10個か。それでデバッグはいつ終わる？」
君「いえ、デバッグはしません」
俺「？」
俺「君、単体テストは終わったかね？」
君「はい、単体テストの結果、NullPointerExcetionが発生する箇所がありました。」
俺「バグが発見したかよくやった！ それでデバッグはいつ終わる？」
君「いえ、これはバグとは言いません。だからデバッグとも言いません」
俺「？」
君「はい、単体テストの結果、NullPointerExcetionが発生する箇所がありました。」
俺「バグが発見したかよくやった！ それでデバッグはいつ終わる？」
君「いえ、これはバグとは言いません。だからデバッグとも言いません」
俺「？」
直ちにプロジェクトに影響を及ぼす数値ではない
debugでバグ取り作業のことなんだけど、ちょっと意訳しすぎちゃった人はいると思う
デバッグというとトレースのことだって思ってる人とかもいる気はする
>>715
契約プログラミングを例えに出すのはあんまり現実的ではないよ
個人や小規模、もしくは逆にものすごく大規模とかならわかるんだけど
そもそもサポートしてくれる言語がマイナーで実用に向かない
全員が理解してるようなメンバー集めるのもちょっとアレだし、学習コストが無駄にかかる
デバッグというとトレースのことだって思ってる人とかもいる気はする
>>715
契約プログラミングを例えに出すのはあんまり現実的ではないよ
個人や小規模、もしくは逆にものすごく大規模とかならわかるんだけど
そもそもサポートしてくれる言語がマイナーで実用に向かない
全員が理解してるようなメンバー集めるのもちょっとアレだし、学習コストが無駄にかかる
100歩譲ってぬるぽなどは単体テストをする前の
開発段階ででないようにするべきだ。
と言いたいと解釈してあげたとしてもだ、
それをバグと呼ばないというだけで
例外だと
バグを見つけるのが簡単になる
↓
開発のミスの把握が簡単になる。
と呼び名が変わるだけ。
開発段階ででないようにするべきだ。
と言いたいと解釈してあげたとしてもだ、
それをバグと呼ばないというだけで
例外だと
バグを見つけるのが簡単になる
↓
開発のミスの把握が簡単になる。
と呼び名が変わるだけ。
他の会社はどういうか知らんけど、うちは
リリース後の動作不良をバグという。
開発行程のものをわざわざバグと言わない。
開発途中である以上、そこで確認できた
問題は、想定外の動作では無いからね。
全てのレビューとテストを掻い潜って初めてバグ扱いになる。
リリース後の動作不良をバグという。
開発行程のものをわざわざバグと言わない。
開発途中である以上、そこで確認できた
問題は、想定外の動作では無いからね。
全てのレビューとテストを掻い潜って初めてバグ扱いになる。
>>706
カスはお前だ。いや、カスに失礼だったな。
自作例外はあくまで例として書いただけであって、本当にそうするわけじゃねーよ。そのぐらい分かれ低能。
それとさ、お前は仕様外の引数が入ってきた場合どうするつもりだよ？
契約プログラムでも使ってるならともかく、そうでないなら実行時にチェックする以外にあるめぇ。
それとも何か？ テストを十分にすれば、仕様外の引数が入る確率が０になるとか妄想抱いてるのか？
当たり前だが、よっぽどのことがない限り、仕様外の引数が入ってくる可能性はあるんだよ。
あまりに例外的なケースは除くとしてな。
そんな場合は例外以外に手段があるとでもいうのか？
カスはお前だ。いや、カスに失礼だったな。
自作例外はあくまで例として書いただけであって、本当にそうするわけじゃねーよ。そのぐらい分かれ低能。
それとさ、お前は仕様外の引数が入ってきた場合どうするつもりだよ？
契約プログラムでも使ってるならともかく、そうでないなら実行時にチェックする以外にあるめぇ。
それとも何か？ テストを十分にすれば、仕様外の引数が入る確率が０になるとか妄想抱いてるのか？
当たり前だが、よっぽどのことがない限り、仕様外の引数が入ってくる可能性はあるんだよ。
あまりに例外的なケースは除くとしてな。
そんな場合は例外以外に手段があるとでもいうのか？
あるだろ。
729 ：仕様書無しさん：2011/03/19(土) 22:06:25.14
【システム障害】 みずほ銀行 高い信頼性を求められる銀行システムに何が起きたのか？ 大規模障害を招いた「夜間バッチ処理」
http://ninja.2ch.net/test/read.cgi/newsplus/1300525602/
http://ninja.2ch.net/test/read.cgi/newsplus/1300525602/
ブレークポイントとかログ出力とかは
デバッグのためにわざわざ作業を追加しないといけない。
例外は本来プログラムのエラー処理として
つくるものなので、そのついでにデバッグの
助けとなる情報が出力されるというのは
素晴らしいことだよ。
もちろん例外だけを使ってブレークポイントなどを
使うなって話ではなく両方を使う。
デバッグのためにわざわざ作業を追加しないといけない。
例外は本来プログラムのエラー処理として
つくるものなので、そのついでにデバッグの
助けとなる情報が出力されるというのは
素晴らしいことだよ。
もちろん例外だけを使ってブレークポイントなどを
使うなって話ではなく両方を使う。
【結構迷う】C vs. C++【どっちで行こうか】
http://hibari.2ch.net/test/read.cgi/tech/1207419469/
http://hibari.2ch.net/test/read.cgi/tech/1207419469/
throwの追加も作業ですよ
ライブラリなら、ライブラリ制作側が
作っているので、throwの追加は必要ないよ。
自分で作ったところであっても
エラー値で返す代わりに例外を返すだけだし、
そうすると、付属してエラーが起きたファイル名や行番号
それを呼び出すに至ったスタックトレースの表示が追加される。
エラーの値 ＜ エラーの値＋ファイル名＋行番号＋スタックトレース
作っているので、throwの追加は必要ないよ。
自分で作ったところであっても
エラー値で返す代わりに例外を返すだけだし、
そうすると、付属してエラーが起きたファイル名や行番号
それを呼び出すに至ったスタックトレースの表示が追加される。
エラーの値 ＜ エラーの値＋ファイル名＋行番号＋スタックトレース
-1という値を見て、これがエラーかどうかは
マニュアルを見ないとわからない。
しかし例外だと、それがエラーだとわかる。
これで出来ることがの一つがデバッガのエラー対応
例外が出たら停止するというブレークポイントの設定が行える。
マニュアルを見ないとわからない。
しかし例外だと、それがエラーだとわかる。
これで出来ることがの一つがデバッガのエラー対応
例外が出たら停止するというブレークポイントの設定が行える。
C#だと行番号なんか出ないんだけど、なんの言語で例外に行番号が出るわけ？
つーか、出るわけねーだろ。そりゃ開発環境でやってるからだ。
インスコーラー作って、ソースのねー開発環境じゃねーところで例外出してみろ
インスコーラー作って、ソースのねー開発環境じゃねーところで例外出してみろ
はぁ。
>>738
ソースのないところで、行番号でてなんか意味あるわけ？
ソースのないところで、行番号でてなんか意味あるわけ？
>>742
違うよ。
お前はあれか？ 例外を使うときソースがある場合だけしか使わんのか。
ライブラリが例外ださねーとでもいうつもりか？
運用中に例外吐かねーとか言うつもりか？
デバッグ中にだけ役立つ情報見てどうするんだよ。
大体、ソースある環境だったら、例外情報見るより、ソース見てデバッガ回した方が確実だ
違うよ。
お前はあれか？ 例外を使うときソースがある場合だけしか使わんのか。
ライブラリが例外ださねーとでもいうつもりか？
運用中に例外吐かねーとか言うつもりか？
デバッグ中にだけ役立つ情報見てどうするんだよ。
大体、ソースある環境だったら、例外情報見るより、ソース見てデバッガ回した方が確実だ
>>743
違うわけ無いだろｗ
例外を使っていれば行番号が出ること
ぐらい知っているはず
その上ででないと言えるわけ無いだろう。
お前はあれか？ 例外を使うときソースがある場合で使わんのか。
つまりお前は開発をしたことがない。ってことになるが。
違うわけ無いだろｗ
例外を使っていれば行番号が出ること
ぐらい知っているはず
その上ででないと言えるわけ無いだろう。
お前はあれか？ 例外を使うときソースがある場合で使わんのか。
つまりお前は開発をしたことがない。ってことになるが。
デバッガを正しく使えないプログラマ多いね。スレ立てたら？
> デバッグ中にだけ役立つ情報見てどうするんだよ。
バグ直すんじゃねーの？
そもそも、「デバッグ中だけで役に立つ情報」があるからこそ
デバッガ使うんだろうが。
どちらでも同じように情報がわかるなら、あえてデバッグする意味ないよなｗ
お前本当にプログラマか？
バグ直すんじゃねーの？
そもそも、「デバッグ中だけで役に立つ情報」があるからこそ
デバッガ使うんだろうが。
どちらでも同じように情報がわかるなら、あえてデバッグする意味ないよなｗ
お前本当にプログラマか？
>>744
だから、デバッグ時にのみ使える情報だったら、こっちの方がマシだろ。
http://www.dotup.org/uploda/www.dotup.org1445336.png
ついでに、>>747
リリースビルドだと出るが、インストーラーでソースのない環境だと当然でない。
http://www.dotup.org/uploda/www.dotup.org1445340.png
大体、ソースのない環境で行番号ってどうやるんだ？ 意味不明なんだが……
使えない情報だわ。マジで
だから、デバッグ時にのみ使える情報だったら、こっちの方がマシだろ。
http://www.dotup.org/uploda/www.dotup.org1445336.png
ついでに、>>747
リリースビルドだと出るが、インストーラーでソースのない環境だと当然でない。
http://www.dotup.org/uploda/www.dotup.org1445340.png
大体、ソースのない環境で行番号ってどうやるんだ？ 意味不明なんだが……
使えない情報だわ。マジで
>>748
落ち着け、その画像は例外だぞｗ
スタックトレースよりも例外をブレークポイントで
止めたほうがより情報がわかるいう話ならわかるが、
そもそも例外が意味ないって話じゃなかったのか？ｗ
いや、そもそもは例外に行番号がでないって話だっけ？ｗ
ソースがない環境でも、行番号出るぞ。
リリースビルドを他のマシンに持って行って実行したから確かだ。
落ち着け、その画像は例外だぞｗ
スタックトレースよりも例外をブレークポイントで
止めたほうがより情報がわかるいう話ならわかるが、
そもそも例外が意味ないって話じゃなかったのか？ｗ
いや、そもそもは例外に行番号がでないって話だっけ？ｗ
ソースがない環境でも、行番号出るぞ。
リリースビルドを他のマシンに持って行って実行したから確かだ。
> 大体、ソースのない環境で行番号ってどうやるんだ？ 意味不明なんだが……
>
> 使えない情報だわ。マジで
そりゃ、ソースコードがないところで行番号でても
意味ないだろｗ
意味の話をしてないというのなら、
使えないとか言うなよｗ
>
> 使えない情報だわ。マジで
そりゃ、ソースコードがないところで行番号でても
意味ないだろｗ
意味の話をしてないというのなら、
使えないとか言うなよｗ
ソースのないところでは使えないだろとか、
ブレークポイントだってソースのないところじゃ使えないだろ・・・
もうね。各種デバッガ技術は
ソースも開発環境もないところでは使えないとか
早く言えばいいのに。
ブレークポイントだってソースのないところじゃ使えないだろ・・・
もうね。各種デバッガ技術は
ソースも開発環境もないところでは使えないとか
早く言えばいいのに。
まあまあReleaseBuildでは行番号が出ないってことにしてあげようよ
でそれが例外が使えない理由にどう繋がるかがわからん
でそれが例外が使えない理由にどう繋がるかがわからん
もうね。何かに役に立つことがあるというのに、
それ以外では役に立たないから
意味が無いという、そういう考え方は馬鹿だと思うわ。
それ以外では役に立たないから
意味が無いという、そういう考え方は馬鹿だと思うわ。
ありがとう。
一連の議論で例外投げるよりassertでコア吐かせる方が有用だということがわかった。
一連の議論で例外投げるよりassertでコア吐かせる方が有用だということがわかった。
と、涙がらに訴えるのであった。
※assertはリリースビルドでは
意味がありません
※assertはリリースビルドでは
意味がありません
リリースビルドじゃないとリリースしちゃいけないと勘違いしてない？
あと、ちゃんとコンパイルオプションとか把握してる？
そもそもＣ＃ってほぼ完璧に元に戻せるしな
Reflector使ってびっくりしたわ
定数は戻せないけどホントにそれだけだしな
Reflector使ってびっくりしたわ
定数は戻せないけどホントにそれだけだしな
前にもいたけどassertと例外の使い方の違いを知らない人がいるね。
例外の代わりにassetを使うとか、それはない。
使い方が違うんだから。
わかり易い例でいうと引数をともなう関数Aがあったとして、
その関数Aの中で引数のチェックをするときは例外を使う。
逆に関数Aを呼び出す前に関数Aの引数を
チェックしたいときはassertを使う。
例外の代わりにassetを使うとか、それはない。
使い方が違うんだから。
わかり易い例でいうと引数をともなう関数Aがあったとして、
その関数Aの中で引数のチェックをするときは例外を使う。
逆に関数Aを呼び出す前に関数Aの引数を
チェックしたいときはassertを使う。
760 ：仕様書無しさん：2011/03/20(日) 19:19:57.02
>>752
誰も例外が使えないとは言ってないんだが……
実際例外ってのは、製品出荷後も使うものだろ。
その時に、行番号なんて出力されないじゃないか。
それだから出ないと言っている。その際に役立つ例外情報ってのは、基本行番号抜きだろ。
基本、例外の中の行番号が出ないと言ってるんだよ。
例外自体は使えるわ。
お前らみたいなのが行番号が出るからとか言って、数千行のメソッド書いて役に立たんスタックトレースでも吐かせるんだろうよ。
誰も例外が使えないとは言ってないんだが……
実際例外ってのは、製品出荷後も使うものだろ。
その時に、行番号なんて出力されないじゃないか。
それだから出ないと言っている。その際に役立つ例外情報ってのは、基本行番号抜きだろ。
基本、例外の中の行番号が出ないと言ってるんだよ。
例外自体は使えるわ。
お前らみたいなのが行番号が出るからとか言って、数千行のメソッド書いて役に立たんスタックトレースでも吐かせるんだろうよ。
>>765
assertは実行時に無くなっても良い場所で使うんだよ。
それは関数の中でのみ必要とされるチェック。
つまり関数のロジックのチェックにのみ使うものだ。
assertは関数のインターフェース、引数のチェックには
使ってはいけないんだよ。実行時にどんな値が入るかわからないからな。
assertは実行時に無くなっても良い場所で使うんだよ。
それは関数の中でのみ必要とされるチェック。
つまり関数のロジックのチェックにのみ使うものだ。
assertは関数のインターフェース、引数のチェックには
使ってはいけないんだよ。実行時にどんな値が入るかわからないからな。
リリースビルドじゃないとリリースしちゃいけないと勘違いしてない？
えっ
>>767
リリースビルドでリリースしてはいけないと思ってないか？ｗ
assertを使ったばかりに、リリースビルドでリリースできなくなるのは
愚の骨頂だ。だからそういう所にassetを使うなということになる。
分かったか？
リリースビルドでリリースしてはいけないと思ってないか？ｗ
assertを使ったばかりに、リリースビルドでリリースできなくなるのは
愚の骨頂だ。だからそういう所にassetを使うなということになる。
分かったか？
>761
だから行番号が出なかったら何やねん
何が言いたいねん
しかも行番号が出なくても困らんと言ってる人間が
糞長いメソッドを書くというレッテル貼りに繋がる理由もわからん
お前主張が支離滅裂だぞ
だから行番号が出なかったら何やねん
何が言いたいねん
しかも行番号が出なくても困らんと言ってる人間が
糞長いメソッドを書くというレッテル貼りに繋がる理由もわからん
お前主張が支離滅裂だぞ
>>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を返す)」とかを参照してくれって方が間違いが少なくて済む。
こういうことけ？
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を返す)」とかを参照してくれって方が間違いが少なくて済む。
>>771
> こういうことけ？
そういうこと。assertはリリースビルドで
消えるというところが鍵
リリースビルドとデバッグビルドで動作（関数の仕様）が
変わってはいけない。privateメソッドならまだ考える余地はあるが、
少なくともpublicメソッドなら、変な引数を与えたら例外を返すという
仕様なのだから、それがリリースビルドで変わるというのはありえない。
> 理由は、例外処理で
その理由はありえない。
> なんで例外飛ぶのかわからない？
falseや-1を返したところで、それと同じように「なんでエラーを戻すかわからない。
エラーを無視して無動くから問題はない。」となるだけだろう？
状況は全く同じだ。
コメントとかjavadoc/doxygenに書いた「userIdにnull・空文字入れたら例外を返す」とかを参照してくれって方が間違いが少なくて済む。
これも状況は全く同じだ。
> こういうことけ？
そういうこと。assertはリリースビルドで
消えるというところが鍵
リリースビルドとデバッグビルドで動作（関数の仕様）が
変わってはいけない。privateメソッドならまだ考える余地はあるが、
少なくともpublicメソッドなら、変な引数を与えたら例外を返すという
仕様なのだから、それがリリースビルドで変わるというのはありえない。
> 理由は、例外処理で
その理由はありえない。
> なんで例外飛ぶのかわからない？
falseや-1を返したところで、それと同じように「なんでエラーを戻すかわからない。
エラーを無視して無動くから問題はない。」となるだけだろう？
状況は全く同じだ。
コメントとかjavadoc/doxygenに書いた「userIdにnull・空文字入れたら例外を返す」とかを参照してくれって方が間違いが少なくて済む。
これも状況は全く同じだ。
例外を使ってない → 例外がない言語を使っている → C言語 → 開発効率が悪い → 規模が小さい → 一人で作っている。
これに当てはまってる状態の人には分かりにくい話なのかもしれないけど
（public）関数を作った時点で、この関数は他人が呼び出すもの。
他人を信用しないコードを書かなくてはならない。
でないと、この関数は○○を引数に与えると
不正な動作をする。というバグとして報告されることになる。
これに当てはまってる状態の人には分かりにくい話なのかもしれないけど
（public）関数を作った時点で、この関数は他人が呼び出すもの。
他人を信用しないコードを書かなくてはならない。
でないと、この関数は○○を引数に与えると
不正な動作をする。というバグとして報告されることになる。
>>771
> 漏れなら、publicメソッドの引数チェックはifを使うが、例外はあんまり使わん。falseとか-1(エラーを示す値)を返すほうが多いかも。
これは意味が分からない。
ifを使うが例外を使わないとはどういう事だ？
普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない。
またfalseや-1を返す場合にしてもifを使うだろ？
お前の言う引数チェックパラノイアは、falseや-1を返したところで
同じように発生してるじゃないか。
> 漏れなら、publicメソッドの引数チェックはifを使うが、例外はあんまり使わん。falseとか-1(エラーを示す値)を返すほうが多いかも。
これは意味が分からない。
ifを使うが例外を使わないとはどういう事だ？
普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない。
またfalseや-1を返す場合にしてもifを使うだろ？
お前の言う引数チェックパラノイアは、falseや-1を返したところで
同じように発生してるじゃないか。
>>772
「変な引数を与えたら例外を返すという仕様」
なんて誰が決めたのか知らんよ、俺は。
C++とかJavaとかC#とかRubyとかPythonとかPerlにそんな仕様はねえ。
……いや、仕様書ちゃんと読んでないだけかも知らんが、「引数に問題がある際は必ず例外をスローすること」と
記載された文章を俺は知らん。
申し訳ないが教えて欲しい。俺ヘタ打ったかもしれんからな。
「変な引数を与えたら例外を返すという仕様」
なんて誰が決めたのか知らんよ、俺は。
C++とかJavaとかC#とかRubyとかPythonとかPerlにそんな仕様はねえ。
……いや、仕様書ちゃんと読んでないだけかも知らんが、「引数に問題がある際は必ず例外をスローすること」と
記載された文章を俺は知らん。
申し訳ないが教えて欲しい。俺ヘタ打ったかもしれんからな。
>>776
俺だが？
つまりおまいは「引数のエラーは必ず例外を出すこと」と決めて他人に強制してるわけな。
俺だったら「例外にしても例外にしなくてもいい。でも、どうしてそうしたのか理由は聞かせてね♪」位にする。
「必ず〜でなければならない」なんてことはないんでな。
俺だが？
つまりおまいは「引数のエラーは必ず例外を出すこと」と決めて他人に強制してるわけな。
俺だったら「例外にしても例外にしなくてもいい。でも、どうしてそうしたのか理由は聞かせてね♪」位にする。
「必ず〜でなければならない」なんてことはないんでな。
>>777
お前は話の流れを理解していない。
見当違いのレスをしてるよ。
assertはコンパイル時に消えるのだから
（お前が作った）仕様がデバッグビルドと
リリースビルドで動作が変わるような使い方を
してはいけないという話だろ。
そして、引数のチェックは例外。
assertは自分が作ったコードの動作確認のために
使うものだ。とそういう話だ。
お前は話の流れを理解していない。
見当違いのレスをしてるよ。
assertはコンパイル時に消えるのだから
（お前が作った）仕様がデバッグビルドと
リリースビルドで動作が変わるような使い方を
してはいけないという話だろ。
そして、引数のチェックは例外。
assertは自分が作ったコードの動作確認のために
使うものだ。とそういう話だ。
あと、「必ず」なんて
ひとことも言ってないわ。
自分の脳内で作り上げた話に
自分で文句付けるな
ひとことも言ってないわ。
自分の脳内で作り上げた話に
自分で文句付けるな
>>779
言ってないが
「普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない」
って書いてるだろ。
つまりお前は引数のエラーには例外飛ばすのが常識なんだわ。
そうでなければおかしいと思っている。
んだからわざわざ「必ず」なんて書いてさしあげましたわ♪ って感じ。
つか突っかかってきたのはお前だぜ？
言ってないが
「普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない」
って書いてるだろ。
つまりお前は引数のエラーには例外飛ばすのが常識なんだわ。
そうでなければおかしいと思っている。
んだからわざわざ「必ず」なんて書いてさしあげましたわ♪ って感じ。
つか突っかかってきたのはお前だぜ？
……あー、不毛だな。
いやならこなくていいんだぞｗ
さっさと消えてもたったほうが
俺の思うつぼだ。
さっさと消えてもたったほうが
俺の思うつぼだ。
例外機能がある言語の標準ライブラリで
エラーに例外を使わない言語なんてないよ。
引数のエラーに例外を使うのは
業界の常識。
エラーに例外を使わない言語なんてないよ。
引数のエラーに例外を使うのは
業界の常識。
>>784
お前、自分が見当違いのはないしてるのわかってないの？
話し戻すぞ。
>>771
> こういうことけ？
そういうこと。assertはリリースビルドで
消えるというところが鍵
リリースビルドとデバッグビルドで動作（関数の仕様）が
変わってはいけない。privateメソッドならまだ考える余地はあるが、
少なくともpublicメソッドなら、変な引数を与えたら例外を返すという
仕様なのだから、それがリリースビルドで変わるというのはありえない。
> 理由は、例外処理で
その理由はありえない。
> なんで例外飛ぶのかわからない？
falseや-1を返したところで、それと同じように「なんでエラーを戻すかわからない。
エラーを無視して無動くから問題はない。」となるだけだろう？
状況は全く同じだ。
コメントとかjavadoc/doxygenに書いた「userIdにnull・空文字入れたら例外を返す」とかを参照してくれって方が間違いが少なくて済む。
これも状況は全く同じだ。
お前、自分が見当違いのはないしてるのわかってないの？
話し戻すぞ。
>>771
> こういうことけ？
そういうこと。assertはリリースビルドで
消えるというところが鍵
リリースビルドとデバッグビルドで動作（関数の仕様）が
変わってはいけない。privateメソッドならまだ考える余地はあるが、
少なくともpublicメソッドなら、変な引数を与えたら例外を返すという
仕様なのだから、それがリリースビルドで変わるというのはありえない。
> 理由は、例外処理で
その理由はありえない。
> なんで例外飛ぶのかわからない？
falseや-1を返したところで、それと同じように「なんでエラーを戻すかわからない。
エラーを無視して無動くから問題はない。」となるだけだろう？
状況は全く同じだ。
コメントとかjavadoc/doxygenに書いた「userIdにnull・空文字入れたら例外を返す」とかを参照してくれって方が間違いが少なくて済む。
これも状況は全く同じだ。
あーつまり
引数チェックでアレなら絶対例外飛ばすべきだ
って言いたいのか？
引数チェックでアレなら絶対例外飛ばすべきだ
って言いたいのか？
>>787
なんでassertの話をしないの？
なんでassertの話をしないの？
>>788
お前の話が抽象的過ぎてぜんぜん意味不明だから。
お前の話が抽象的過ぎてぜんぜん意味不明だから。
いや、お前が何言いたいのかさっぱりわからないからもっと具体的に言えっってこと。
>>794
お前が理解できてないだけじゃねｗ
お前が理解できてないだけじゃねｗ
assertをどういうときに使うかは
常識なんで、わからないなら
ぐぐればいいじゃないですか？
ググりましたか？
常識なんで、わからないなら
ぐぐればいいじゃないですか？
ググりましたか？
「引数に変な値を突っ込んだ際、必ず例外を返す言語処理系を書け」
と言ってるんだよ。
と言ってるんだよ。
ほら、「assert 例外 違い」でググッてきてやったぜ
勉強してから出直しな。
http://nokamoto.web.fc2.com/programming/assert_vs_exception.html
http://i-learn-try-error-and-try.blogspot.com/2009/04/assertexception.html
勉強してから出直しな。
http://nokamoto.web.fc2.com/programming/assert_vs_exception.html
http://i-learn-try-error-and-try.blogspot.com/2009/04/assertexception.html
もちろんその言語系の標準クラスの全メソッド書いてもらうけどな。
そこまでしてもらわないと信じられないね。
>>796
というか、正直全部例外返すとか正気け？ って思ったんだよ。
例えばRubyの String#to_i とか、「整数とみなせない文字があればそこまでを変換対象とします」ってあるだろ。
http://www.ruby-lang.org/ja/man/html/String.html#to_i
お前の話なら例外をスローしないとおかしい。
つか「public関数で引数がアレなら絶対例外飛ばすべきで戻り値でエラー伝達してはいけない」
なんていう話の方がおかしいんじゃね？ という話なんだが。
おまいの中では例外でなければならないのはわかった。
assertをprivateメソッドで使っちゃダメなんですねーハイハイカワイソス状態。
そこまでしてもらわないと信じられないね。
>>796
というか、正直全部例外返すとか正気け？ って思ったんだよ。
例えばRubyの String#to_i とか、「整数とみなせない文字があればそこまでを変換対象とします」ってあるだろ。
http://www.ruby-lang.org/ja/man/html/String.html#to_i
お前の話なら例外をスローしないとおかしい。
つか「public関数で引数がアレなら絶対例外飛ばすべきで戻り値でエラー伝達してはいけない」
なんていう話の方がおかしいんじゃね？ という話なんだが。
おまいの中では例外でなければならないのはわかった。
assertをprivateメソッドで使っちゃダメなんですねーハイハイカワイソス状態。
あと、どうも俺が「標準ライブラリは例外を返している」の
”標準”の部分を無視してきそうだから、
ここらで釘を挿しとくかｗ
”標準”の部分を無視してきそうだから、
ここらで釘を挿しとくかｗ
> もちろんその言語系の標準クラスの全メソッド書いてもらうけどな。
ググれよｗ
コピペする面倒を俺がやることで
ネット上で見れるマニュアをみること以上の
意味がなんかあるのか？
ググれよｗ
コピペする面倒を俺がやることで
ネット上で見れるマニュアをみること以上の
意味がなんかあるのか？
いや「標準ライブラリ」って書いたろ、お前。
処理系はライブラリとは違うとか言って、お前は標準ライブラリって書いたんだから >>793
処理系はライブラリとは違うとか言って、お前は標準ライブラリって書いたんだから >>793
>>800
> 例えばRubyの String#to_i とか、「整数とみなせない文字があればそこまでを変換対象とします」ってあるだろ。
それ例外の代わりにエラーを返してるわけじゃないじゃんｗ
それはエラーを返さないという仕様なだけ。
俺が言ってるのは「エラー状態を値で返すのではなく例外で返す」って話だぞ。
そもそもエラーにならない場合の話なんかしてないわｗ
> 例えばRubyの String#to_i とか、「整数とみなせない文字があればそこまでを変換対象とします」ってあるだろ。
それ例外の代わりにエラーを返してるわけじゃないじゃんｗ
それはエラーを返さないという仕様なだけ。
俺が言ってるのは「エラー状態を値で返すのではなく例外で返す」って話だぞ。
そもそもエラーにならない場合の話なんかしてないわｗ
……あーなんか久々にマジイラっとした。
たぶん漏れがイラっとしたのは「そうすべきだ！」みたいなのを見たときだと思うけどな。
戻り値で返したほうがいいかって判断のときもある。
十把ひとからげで機械的に例外とか言われるとマジムカつくんだよ。
「assert」とは「前提条件の宣言」であって、俺はこういう前提を考えてるっていうメモ書きでしかない。
例えばprivateメソッドの中身は俺に責任と支配権がある。
private関数の引数でミスってたら俺の責任だし俺が直すべきもの。だからassertでいい。
また、処理の途中で「必ず変数はこうなっているはず」ってのをメモ書きする程度でassertを使うことはある。
publicメソッドで全部例外飛ばすのが仕様なら、別インスタンスのメソッドは全部try-catchしなきゃいかんわけ。
AnyClass a = new AnyClass();
try {
a.anyFunc();
} catch (AnyException e) {
// なんかしてくれ。俺は知らん。
}
ってのを全インスタンスの全メソッドでやるべきだってことだ。
そこまでしたいならそうしてくれ。俺はよー面倒見きれんよ。
たぶん漏れがイラっとしたのは「そうすべきだ！」みたいなのを見たときだと思うけどな。
戻り値で返したほうがいいかって判断のときもある。
十把ひとからげで機械的に例外とか言われるとマジムカつくんだよ。
「assert」とは「前提条件の宣言」であって、俺はこういう前提を考えてるっていうメモ書きでしかない。
例えばprivateメソッドの中身は俺に責任と支配権がある。
private関数の引数でミスってたら俺の責任だし俺が直すべきもの。だからassertでいい。
また、処理の途中で「必ず変数はこうなっているはず」ってのをメモ書きする程度でassertを使うことはある。
publicメソッドで全部例外飛ばすのが仕様なら、別インスタンスのメソッドは全部try-catchしなきゃいかんわけ。
AnyClass a = new AnyClass();
try {
a.anyFunc();
} catch (AnyException e) {
// なんかしてくれ。俺は知らん。
}
ってのを全インスタンスの全メソッドでやるべきだってことだ。
そこまでしたいならそうしてくれ。俺はよー面倒見きれんよ。
> publicメソッドで全部例外飛ばすのが仕様なら、別インスタンスのメソッドは全部try-catchしなきゃいかんわけ。
え？ 全部って言った？ ねぇ全部って言った？
全部する必要はないけど？ｗ
戻り値でエラーを返したら、エラーチェックしないといけないよ。
それと何が違うのかね？
あ、全部とは言わないけどｗｗｗ
え？ 全部って言った？ ねぇ全部って言った？
全部する必要はないけど？ｗ
戻り値でエラーを返したら、エラーチェックしないといけないよ。
それと何が違うのかね？
あ、全部とは言わないけどｗｗｗ
>>808
www が増えてるな。大分キレてんだろ？ わかるよ。
かわいそうだな。まあ頑張れ。
>>774みれ。
「普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない。」
お前は「例外を使わないということの意味がわからない」と書いた。
お前には例外を使わない奴の意味がわからない。お前は例外を使うべきだって思っているわけだ。
まあ頑張れ。
www が増えてるな。大分キレてんだろ？ わかるよ。
かわいそうだな。まあ頑張れ。
>>774みれ。
「普通引数チェックでifをして、不正なら例外をだす。
ifを使って例外を使わないといういう事の意味が分からない。」
お前は「例外を使わないということの意味がわからない」と書いた。
お前には例外を使わない奴の意味がわからない。お前は例外を使うべきだって思っているわけだ。
まあ頑張れ。
例外は戻り値でエラーを返す方法の欠点を
解決するために作られたものなんだから
戻り値でエラーを返すよりも例外で返すべきなんだよ。
もし、それでも戻り値でエラーを返したくなったら良く考えてみ、
その返そうとしているのは、エラーではなくただの状態フラグだろ。
解決するために作られたものなんだから
戻り値でエラーを返すよりも例外で返すべきなんだよ。
もし、それでも戻り値でエラーを返したくなったら良く考えてみ、
その返そうとしているのは、エラーではなくただの状態フラグだろ。
> ……あーなんか久々にマジイラっとした。
大分キレてんだろ？ わかるよ。
大分キレてんだろ？ わかるよ。
戻り値でも例外でもエラーを無視させたくないって意味では一緒だ。
例外に悪慣れする奴が居る。
ドキュメント見ようとせず、「何かトラブってる？」とたずねても「いえ問題ないです」っつって
とりあえず try - catchで凌いでた奴はいやってほどいたのさ。
んーなら戻り値と例外を織り交ぜて「あのー、この辺意味わかんなくって」って言わせるほうが
マシだってこと。
聞かれれば「あーここね、OK説明しちゃる」と話も出来るから。
例外に悪慣れする奴が居る。
ドキュメント見ようとせず、「何かトラブってる？」とたずねても「いえ問題ないです」っつって
とりあえず try - catchで凌いでた奴はいやってほどいたのさ。
んーなら戻り値と例外を織り交ぜて「あのー、この辺意味わかんなくって」って言わせるほうが
マシだってこと。
聞かれれば「あーここね、OK説明しちゃる」と話も出来るから。
>>811
お互いキレてるんじゃね？
俺がイラっとしたのは「どうもこいつ例外万能主義じゃね？」って思ったことだよ。
「とりあえず例外」みたいな、なんも考えてないような表現のようには見えたんだよ。
そうでないなら俺の誤読だがな。
お互いキレてるんじゃね？
俺がイラっとしたのは「どうもこいつ例外万能主義じゃね？」って思ったことだよ。
「とりあえず例外」みたいな、なんも考えてないような表現のようには見えたんだよ。
そうでないなら俺の誤読だがな。
残念だけどな、ン十名とかン百名とかのプロジェクトに参加すると例外万能とか戻り値でOKとか
そんな原理原則は通用しねーんだわ。
アホの子から天才サマまで居る。
アホの子基準でやらんと破綻する。天才は勝手に何とかするからな。
っつってもアホの子っつってもよくよく話し聞けば「あー、なんだ、参照渡しの意味わかんねーだけか」
みたいな話になるが、うまいこと他人から話引き出せるような書き方せにゃならんのだわ。
assertは俺が管理している内部の処理だけで使う。
例外飛ばすか戻り値でやるかは、問題の重大性による。
DBとか別サーバの接続問題とか、環境の問題であれば例外を飛ばす。
コーディングレベルの問題なら戻り値で処理するのが基本だが、ちょっと悩ましいところなら例外かも。
んで誰か眉ひそめてたら「キター！！！！！」っつってそいつに話しかける。ンで仕舞いだ。
そのくらいだわ、俺は。
別に全部例外にしたっていいが、俺は関わりたくねえな。
そんな原理原則は通用しねーんだわ。
アホの子から天才サマまで居る。
アホの子基準でやらんと破綻する。天才は勝手に何とかするからな。
っつってもアホの子っつってもよくよく話し聞けば「あー、なんだ、参照渡しの意味わかんねーだけか」
みたいな話になるが、うまいこと他人から話引き出せるような書き方せにゃならんのだわ。
assertは俺が管理している内部の処理だけで使う。
例外飛ばすか戻り値でやるかは、問題の重大性による。
DBとか別サーバの接続問題とか、環境の問題であれば例外を飛ばす。
コーディングレベルの問題なら戻り値で処理するのが基本だが、ちょっと悩ましいところなら例外かも。
んで誰か眉ひそめてたら「キター！！！！！」っつってそいつに話しかける。ンで仕舞いだ。
そのくらいだわ、俺は。
別に全部例外にしたっていいが、俺は関わりたくねえな。
無知宣言してる馬鹿いつまでも相手するなよ
最初の方のレスで相手する価値がないことくらい明白じゃないの
最初の方のレスで相手する価値がないことくらい明白じゃないの
で、行番号が出る出ないはなんだったんだ？
あまりに間抜けなことを言ってることに気付いて引っ込めたのか
あまりに間抜けなことを言ってることに気付いて引っ込めたのか
エラーの返し方はいくらでもあるが、
そのメソッド名が表現する処理が完遂できないのは、想定外であり例外だ。
公開するメソッドならもちろんだし、非公開でも、なるべくお作法に従って例外投げれ。
どうしても例外を投げたくなけりゃ、返す値がエラーではない値になるように、
メソッドを相応しい名前へと変更して、戻り値の型をエラーを内包する相応しい物にしろ。
そこまでの事が出来ないなら、例外的なメソッドなんて作らず、お作法通り例外投げれ。
もちろん、いろんなエラー値が帰ってくるような糞関数でも、使うときはさして問題にはならんよ。
検査例外があるJavaはさておき、それ以外の言語の場合は、例外だってドキュメント見なわからん。
その点は戻り値エラーだって同じだ。まぁ例外は型があるから、メソッド名から推測できる場合もあるが。
どちらにせよ、その関数を使おうとしたときは、相応に調べるから問題になることはそうない。
例外自体は絶対に切り離せない仕組みだから、所々に戻り値エラーが混ざる形になって、
コーディングのスタイルは不統一になるが、その程度。大きな問題じゃない。
ぶっちゃけ、んな事は問題じゃない。戻り値エラーの一番糞な所は、改修の時。
例外ならメソッドの想定外だったすぐ判断できるし、回復や中断が明確になる。
だが、戻り値の場合、戻ってきた値の意味を毎回調べるハメになるんだわ。
改修のことまで考えたら、やっぱ戻り値でいろんな意味のある値を返すのは、相応しい選択じゃねぇよ。
業務的な意味の例外なら、いくつも型作るのもアレだから理解できるが、
それ以外でも戻り値エラーにするのは、本気でやめて欲しいわ。
そのメソッド名が表現する処理が完遂できないのは、想定外であり例外だ。
公開するメソッドならもちろんだし、非公開でも、なるべくお作法に従って例外投げれ。
どうしても例外を投げたくなけりゃ、返す値がエラーではない値になるように、
メソッドを相応しい名前へと変更して、戻り値の型をエラーを内包する相応しい物にしろ。
そこまでの事が出来ないなら、例外的なメソッドなんて作らず、お作法通り例外投げれ。
もちろん、いろんなエラー値が帰ってくるような糞関数でも、使うときはさして問題にはならんよ。
検査例外があるJavaはさておき、それ以外の言語の場合は、例外だってドキュメント見なわからん。
その点は戻り値エラーだって同じだ。まぁ例外は型があるから、メソッド名から推測できる場合もあるが。
どちらにせよ、その関数を使おうとしたときは、相応に調べるから問題になることはそうない。
例外自体は絶対に切り離せない仕組みだから、所々に戻り値エラーが混ざる形になって、
コーディングのスタイルは不統一になるが、その程度。大きな問題じゃない。
ぶっちゃけ、んな事は問題じゃない。戻り値エラーの一番糞な所は、改修の時。
例外ならメソッドの想定外だったすぐ判断できるし、回復や中断が明確になる。
だが、戻り値の場合、戻ってきた値の意味を毎回調べるハメになるんだわ。
改修のことまで考えたら、やっぱ戻り値でいろんな意味のある値を返すのは、相応しい選択じゃねぇよ。
業務的な意味の例外なら、いくつも型作るのもアレだから理解できるが、
それ以外でも戻り値エラーにするのは、本気でやめて欲しいわ。
まぁ、業務的な例外の場合、仕様の届く範疇だし、処理済みであるべきなので、
共通的な大元の処理以外で、catch しないといけないような例外として投げるべきではないけどな。
>>817
>>736が前提条件が抜けてる、単にアホな発言だったってだけっしょ。
後の発言見てたら言いたかったことは予想できるし、続ける意味がないっしょ。
>>818
戻り値でエラーを返すために、無理やり値を拡張することを回避する手段だわ。
810はそう言ってるんじゃ。解釈間違えてると思う。
共通的な大元の処理以外で、catch しないといけないような例外として投げるべきではないけどな。
>>817
>>736が前提条件が抜けてる、単にアホな発言だったってだけっしょ。
後の発言見てたら言いたかったことは予想できるし、続ける意味がないっしょ。
>>818
戻り値でエラーを返すために、無理やり値を拡張することを回避する手段だわ。
810はそう言ってるんじゃ。解釈間違えてると思う。
例外は戻り値の代替手段ではなく、
戻り値でエラー値を返すことの代替手段だよ。
戻り値と、エラー値は全くの別物。
例外がない言語では、戻り値の中に特殊なルールを作って
エラー値を混ぜて返す。受け取り側でそれを判断して
戻り値とエラー値で振り分けて処理する。
そういうバッドノウハウを必要なくしたのが例外。
例外をなぜ特殊なものと考えるかな？
どういうときに使うかは、標準ライブラリでも参考にしろよ。
誰も、戻り値をやめて、全部例外にしろとなんて言ってないからな。
戻り値にエラー値を混ぜるのをやめて、それを例外にしろと言ってる。
戻り値でエラー値を返すことの代替手段だよ。
戻り値と、エラー値は全くの別物。
例外がない言語では、戻り値の中に特殊なルールを作って
エラー値を混ぜて返す。受け取り側でそれを判断して
戻り値とエラー値で振り分けて処理する。
そういうバッドノウハウを必要なくしたのが例外。
例外をなぜ特殊なものと考えるかな？
どういうときに使うかは、標準ライブラリでも参考にしろよ。
誰も、戻り値をやめて、全部例外にしろとなんて言ってないからな。
戻り値にエラー値を混ぜるのをやめて、それを例外にしろと言ってる。
戻り値でエラーを返す方法の一番の欠点は
全メソッドでエラーチェックをしないといけないことだ。
AnyClass a = new AnyClass();
a.anyFunc();
（次の命令）
もし、このanyFuncが戻り値でエラー値を返していたら
これではエラーが起きても正常に処理を続行（次の命令を実行）してしまう。
つまり、全部の関数で
AnyClass a = new AnyClass();
if(a.anyFunc() == エラー値) {
//何かする。
}
このような面倒をみないといけない。手間がかかるってのもあるし、
エラー値が関数ごとにバラバラなので、これはエラーの場合なのか？
それとも単に戻り値をチェックしているだけなのか？ってわからない。
こんな欠点があるのに、そこまでしたいならそうしてくれ。俺はよー面倒見きれんよ。
全メソッドでエラーチェックをしないといけないことだ。
AnyClass a = new AnyClass();
a.anyFunc();
（次の命令）
もし、このanyFuncが戻り値でエラー値を返していたら
これではエラーが起きても正常に処理を続行（次の命令を実行）してしまう。
つまり、全部の関数で
AnyClass a = new AnyClass();
if(a.anyFunc() == エラー値) {
//何かする。
}
このような面倒をみないといけない。手間がかかるってのもあるし、
エラー値が関数ごとにバラバラなので、これはエラーの場合なのか？
それとも単に戻り値をチェックしているだけなのか？ってわからない。
こんな欠点があるのに、そこまでしたいならそうしてくれ。俺はよー面倒見きれんよ。
×全メソッドでエラーチェックをしないといけないことだ。
○全メソッドでエラーチェックコードを書かないといけないことだ。
訂正しよう。例外だとエラーチェックをしなくてもいい、それは手抜きだ。と
捉えかねないからなｗ
例外は、「標準のエラーチェックコード」というのが存在している。
例外を使っていれば、何も書かない＝デフォルトのエラーチェック処理。なんだ。
だからエラーチェックをしない。ということがありえない。
○全メソッドでエラーチェックコードを書かないといけないことだ。
訂正しよう。例外だとエラーチェックをしなくてもいい、それは手抜きだ。と
捉えかねないからなｗ
例外は、「標準のエラーチェックコード」というのが存在している。
例外を使っていれば、何も書かない＝デフォルトのエラーチェック処理。なんだ。
だからエラーチェックをしない。ということがありえない。
設計が下手くそなだけじゃねえか
はい、824がどこが下手か指摘して、上手な設計を教えてくれるそーです（爆笑）
>>824
答えられんのなら、でてくるんじゃねーよｗ
答えられんのなら、でてくるんじゃねーよｗ
そこでまた、そもそも例外で処理すべきエラーって何よ？に戻る。
EOFはエラーじゃないだろ？とか
FileNotFoundはどーなのとか。ループループｗ
EOFはエラーじゃないだろ？とか
FileNotFoundはどーなのとか。ループループｗ
>>828
だからそれは正常系と異常系に違いだろ。ループループ
だからそれは正常系と異常系に違いだろ。ループループ
>>828
> そこでまた、そもそも例外で処理すべきエラーって何よ？に戻る。
君は「何を例外で処理すべきか？」と悩んでいるね。
なぜ君が悩んでいるか、その理由を教えてあげようか？
それはね、君のレスにヒントがある。
EOFはエラーか？ FileNotFoundはエラーか？
君は例外だけを考えているから理解出来ないんだよ。
君に聞きたいのは例外ではなく関数の仕様の方だ。関数名でもいい。
もしGetConfigDataという関数で、Configデータを返すという仕様の関数であれば、
ファイルが見つからなければFileNotFound。
FileExistsというファイルチェック関数ならtrue/false（※重要 これはエラー値ではない）
よって例外がある言語で、関数の戻り値にエラー値を返すことはない。
（ファイルが見つからない場合にデフォルト値を戻す仕様だってありえるだろ厨へ。
エラー値を戻すか、例外を戻すか の話なのでデフォルト値を戻すというのは、
仕様が違うってだけで、的外れな答えです）
> そこでまた、そもそも例外で処理すべきエラーって何よ？に戻る。
君は「何を例外で処理すべきか？」と悩んでいるね。
なぜ君が悩んでいるか、その理由を教えてあげようか？
それはね、君のレスにヒントがある。
EOFはエラーか？ FileNotFoundはエラーか？
君は例外だけを考えているから理解出来ないんだよ。
君に聞きたいのは例外ではなく関数の仕様の方だ。関数名でもいい。
もしGetConfigDataという関数で、Configデータを返すという仕様の関数であれば、
ファイルが見つからなければFileNotFound。
FileExistsというファイルチェック関数ならtrue/false（※重要 これはエラー値ではない）
よって例外がある言語で、関数の戻り値にエラー値を返すことはない。
（ファイルが見つからない場合にデフォルト値を戻す仕様だってありえるだろ厨へ。
エラー値を戻すか、例外を戻すか の話なのでデフォルト値を戻すというのは、
仕様が違うってだけで、的外れな答えです）
やることいっしょなばあいだけね。
>>832
エラーを受け取った後にやることはほとんど同じ。
エラーを受け取った後にやることはほとんど同じ。
なんでコンフィグかえすかんすうでファイルのっとファウンドなんか出てくるのかなー
>>833
やること一緒なばあいだけだね
やること一緒なばあいだけだね
>>836
わからないよおればかだから
わからないよおればかだから
>>837
なんとなく分かるｗ
なんとなく分かるｗ
>>836
そんなのしらねーよ。
そんなのしらねーよ。
じゃあ、どこにconfigデータがあると思ってたんだろうか・・・。
いいよ答えなくてｗ
いいよ答えなくてｗ
知る必要があるのか？
知る必要ではなく、君がどこにconfigデータが保存されると思ったかだよ。
そんなのプログラムに関係ないんじゃないのかな
そりゃ、君が、configデータをファイルに保存するということを
思いつかなかったのは、なぜか？って話だからねｗ
思いつかなかったのは、なぜか？って話だからねｗ
ハードコーディングやプロセス間通信によって得られる場合もあるから、
「ファイル」に限定することはできないな。
「ファイル」に限定することはできないな。
馬鹿に構う馬鹿も全部まとめて吹き飛んでしまえ。
書き込むボタンを押す前に、レス返すほど価値のある内容か10秒でいいから考え直せよ馬鹿。
相手を黙らせるまで連投して、最後に書き込んだほうが勝ち、じゃねーんだから半島人みたいなことばっかすんなよ。
書き込むボタンを押す前に、レス返すほど価値のある内容か10秒でいいから考え直せよ馬鹿。
相手を黙らせるまで連投して、最後に書き込んだほうが勝ち、じゃねーんだから半島人みたいなことばっかすんなよ。
普通はファイルに保存するだろ。
ほとんど無いような例引っ張り出して話混ぜ返すなよ。
ほとんど無いような例引っ張り出して話混ぜ返すなよ。
>>846
正直すまんかった
正直すまんかった
>>846
暇つぶしなんじゃね？
暇つぶしなんじゃね？
暇つぶしなら他所でやれよ、馬鹿同士の乳繰り合いは寒いぞ
154 名前：名無しさん＠お腹いっぱい。(東日本)[sage] 投稿日：2011/03/22(火) 21:35:11.33 ID:TWYMWmhX0 [3/3]
幾つの家が壊れたであろう。
幾つの家が流されたのであろう。
そして、幾つもの尊い命が失われた。これが現実。
亡くなった方々のためにも、生きなければならない。
一件の家を建てるのに3,000万。
4万件の家を建てるのには1.2兆円。
国民一人、10,000円あれば達成できる。
いや、1,000円でも100円でもいい。
復興のために少しだけ、力をください！
幾つの家が壊れたであろう。
幾つの家が流されたのであろう。
そして、幾つもの尊い命が失われた。これが現実。
亡くなった方々のためにも、生きなければならない。
一件の家を建てるのに3,000万。
4万件の家を建てるのには1.2兆円。
国民一人、10,000円あれば達成できる。
いや、1,000円でも100円でもいい。
復興のために少しだけ、力をください！
>>852
暇つぶしなら他所でやれよ
暇つぶしなら他所でやれよ
んなコピペしてる暇があったら節電するほうが有意義だと思うの
九州だから節電しても意味ないよｗ
んじゃｶﾈ送ってやれよ屑
みずほが落ちたのは間違った例外処理のせいに違いない
戻り値にしておけば、一部顧客のデータが消えただけで済んだだろうに
戻り値にしておけば、一部顧客のデータが消えただけで済んだだろうに
はぁ？
頭大丈夫？
頭大丈夫？
海外サーバーを経由してネットする方法を詳細に記している「書籍」知りませんか？
別に悪いことするために聞いているのではありませんがｗ
wikileaksのハッカーが、それをしていると聞いて興味を持ちまして
別に悪いことするために聞いているのではありませんがｗ
wikileaksのハッカーが、それをしていると聞いて興味を持ちまして
ただのてきとープロクシのことならどこにでもあるが。
とーあとかかもしらんけどここできくことではないわなあ
862 ：仕様書無しさん：2011/03/27(日) 17:06:02.52
http://mikosuma.com/
あの事件、実は在日の仕業
あの事件、実は在日の仕業
Code Complete読めば？
864 ：仕様書無しさん：2011/04/05(火) 17:31:45.55
tp://blog.livedoor.jp/sharepoint/archives/50102988.html
catch
{
throw;
}
これって何？ メリット有るん？ あるんなら、おせーーて
catch
{
throw;
}
これって何？ メリット有るん？ あるんなら、おせーーて
ない
tryを書いたらcatchしないとだめっておもってる人がたまにやってる
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() まで到達する必要があるからね
> 561 返信：デフォルトの名無しさん[sage] 投稿日：2011/04/28(木) 03:25:09.83
> 次に、>>546のような深いネストがどうしても必要な場合
> 仮に例外で処理するなら error_handler() で catch するだろう
> そうすると途中の関数は例外処理がいらないから(デストラクタで処理できるリソースだけ使ってる場合は)簡単になるけど
> error_handler() を読むのが凄く難しくなる
> 深いネストを潜って source_of_error() まで到達する必要があるからね
どれくらいの粒度でエラー補足したらいいのかいつも迷う
必要なときでいいじゃない？
エラー送信の方では悩むけど
エラー補足で悩む必要あるのか？
エラー送信の方では悩むけど
エラー補足で悩む必要あるのか？
うちは7行に一つくらいはエラーログ出るようになっとるわ。
ほかにも関数ごとに一回くらいとか、スタックトレース的に出るようなマクロ作ってるとか
いろいろやりようがあるわな。その辺は好みでいいだろう。
ただ、長年商売してると顧客サイドで落ちた時にログ収集してもさっぱりわかりません
はつらいからやっぱ多目に越したことはないと思うわ。
ほかにも関数ごとに一回くらいとか、スタックトレース的に出るようなマクロ作ってるとか
いろいろやりようがあるわな。その辺は好みでいいだろう。
ただ、長年商売してると顧客サイドで落ちた時にログ収集してもさっぱりわかりません
はつらいからやっぱ多目に越したことはないと思うわ。
望んだ動作ができなかったら投げる
これが一番簡単
これが一番簡単
サラリーマン的に仕事けるのは大変だし…
例えがさっぱり意味不明ｗ
875 ：仕様書無しさん：2011/05/08(日) 12:15:25.80
>>864
デバッグのときにブレークポイントが貼りやすい的なもんじゃね？
デバッグのときにブレークポイントが貼りやすい的なもんじゃね？
そういや、ブレークポイントって未だに行単位だよな。
return foo();
ってかいて、fooが終了したときにブレークポイント貼りたいんだが。
return foo();
ってかいて、fooが終了したときにブレークポイント貼りたいんだが。
終了したときの状態でとめたい、でもローカル変数使いたく無い、って場合は
foo()のなかの末尾にしかけてステップアウトするか、
開始前でとめてステップオーバーで飛ばすかくらいしかないんじゃねーの
でも見たいのは戻り値だから、結局ローカル変数ないと確認できない気はするけれど
>>878
returnの前にfoo()が評価されっから、877に仕掛けても878と変わらんのじゃね
foo()のなかの末尾にしかけてステップアウトするか、
開始前でとめてステップオーバーで飛ばすかくらいしかないんじゃねーの
でも見たいのは戻り値だから、結局ローカル変数ないと確認できない気はするけれど
>>878
returnの前にfoo()が評価されっから、877に仕掛けても878と変わらんのじゃね
eax 見ればいいんじゃねーの？
foo()が戻した値をそのまま戻すんだから、その関数の戻り値を確認すればいいんじゃないの？
cとかはブレークポイント張りにくいから
関数の引数に関数を入れるような
入れ子にせず、一行づつ書く、
戻り値はいちいち変数に入れる
というマナーがあるよね。
最近は古い慣習という扱いなのかな。
関数の引数に関数を入れるような
入れ子にせず、一行づつ書く、
戻り値はいちいち変数に入れる
というマナーがあるよね。
最近は古い慣習という扱いなのかな。
そうすべきかどうかはその関数の性質によると思うな。
入出力も副作用もない数学の関数のようなものなら、必要がなければいちいち
変数に入れたりはしないと思う。
入出力も副作用もない数学の関数のようなものなら、必要がなければいちいち
変数に入れたりはしないと思う。
たしかに、画面に描画する関数を引数には
しないですね。妥当だとおもいます。
上記のマナーは、一切の入れ子禁止と
言うものでした。
しないですね。妥当だとおもいます。
上記のマナーは、一切の入れ子禁止と
言うものでした。
foo(bar())
こんなコード書いていて、bar()が終了したときの値を見たい。
こんなコード書いていて、bar()が終了したときの値を見たい。
アセンブラレベルでデバッグしろよ。
ブレークポイントをbarの先頭にかけて、
（barを）抜けるところまでスキップ。
（barを）抜けるところまでスキップ。
需要も0ではなく、そういう用途に使いたいときもあって
機能として実現も無理ではないはずだが、わかりやすい形での実装はみたことないな
大抵はコードのほうを無理くり対応させる形で目的を達成してる感
機能として実現も無理ではないはずだが、わかりやすい形での実装はみたことないな
大抵はコードのほうを無理くり対応させる形で目的を達成してる感
あんまり関係ないんだが、DBのRollbackって明示的にする必要あんの？
Beginでトランザクション開始後、切断ないしクライアントの応答が途絶えたら自動でRollback。
Beginのあともう一回Beginを行うと、その間のトランザクションは、Rollbackまたはスタックされる。
スタックされた場合でも、Beginとcommitの数が一致しなければその間のトランザクションは全てRollbackされる。
接続を細かく切ってるようなら、わざわざ例外ブロックにRollback書く必要もないよな。
状況の情報を加えた例外は出す必要はあるけど。
Beginでトランザクション開始後、切断ないしクライアントの応答が途絶えたら自動でRollback。
Beginのあともう一回Beginを行うと、その間のトランザクションは、Rollbackまたはスタックされる。
スタックされた場合でも、Beginとcommitの数が一致しなければその間のトランザクションは全てRollbackされる。
接続を細かく切ってるようなら、わざわざ例外ブロックにRollback書く必要もないよな。
状況の情報を加えた例外は出す必要はあるけど。
今時はコネプーだから、接続を細かく切るってのが想像できん。
Javaのこねぷ〜でも切断する訳じゃないけど、getConnection()するしclose();すんじゃん。
GUI環境だからって接続しっぱなしにしてんの？
連続でやりとりすんならまだしも、
クライアント操作が無い間中DBサーバーのリソース食うのに。
連続でやりとりすんならまだしも、
クライアント操作が無い間中DBサーバーのリソース食うのに。
そういうバカなのもあるよ。去年だか一昨年だかに関わったわ
そういう仕様がご所望だったらしくて、苦笑いしながらやった記憶がある
つか、rollbackにしろなんにしろ、こうであるっていう前提で明示的にしないほうがアレだろ
むしろ明示することのデメリットを知りたいわ
DBによっちゃオートコミットとかの設定がされてて全く逆の事になる場合だってあるだろっていう
そういう仕様がご所望だったらしくて、苦笑いしながらやった記憶がある
つか、rollbackにしろなんにしろ、こうであるっていう前提で明示的にしないほうがアレだろ
むしろ明示することのデメリットを知りたいわ
DBによっちゃオートコミットとかの設定がされてて全く逆の事になる場合だってあるだろっていう
あ、もちろんクライアントの数が不特定でそれなりに数あるってやつなｗ
なんか変なこと書いたな。オートコミットは毎回コミットだからこの話には関係はないわな忘れてくれ
>>895
明示したいかどうかはどうでもいいんだけど、ここのスレって眺めてると例外の使用例にやたら
rollbackが多い気がすんだよ。だから、さもrollbackが重大な処理で例外処理なら
rollback(もしくはリソース開放)みたいなレスにクギを刺しとこうかと思ってね。
そこは例外の重要な用途でも本質でもないからこだわんなと。
明示したいかどうかはどうでもいいんだけど、ここのスレって眺めてると例外の使用例にやたら
rollbackが多い気がすんだよ。だから、さもrollbackが重大な処理で例外処理なら
rollback(もしくはリソース開放)みたいなレスにクギを刺しとこうかと思ってね。
そこは例外の重要な用途でも本質でもないからこだわんなと。
ロールバック、リソース開放ごときに例外を使うなってこと？
それとも、もっと多彩な例を挙げろという要求？
いまいち意図がみえない
それとも、もっと多彩な例を挙げろという要求？
いまいち意図がみえない
具体的にrollbackなんかより実用的で多彩な例をあげろって事。
例外って、ほんとに使いやすいの？ やたらあちこちに例外使ってる奴いるけど
gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる
全てのエラーを例外使うんじゃなく適材適所が良い気がする
gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる
全てのエラーを例外使うんじゃなく適材適所が良い気がする
学生時代にgoto駄目だって習ったけど、小さい関数内で一個つかうくらいなら、べつによくねって感じで使ってることあるわ
>>898
rollbackはどうでもいいんだけど、ここのスレって眺めてるとやたらバカが多い気がすんだよ。
>rollback(もしくはリソース開放)みたいなレスにクギを刺しとこうかと思ってね。
リソースは開放じゃなく解放だから、ちゃんとクギを刺しとこうかと思ってねｗ
あと、899,900も日本語がおかしいｗ
rollbackはどうでもいいんだけど、ここのスレって眺めてるとやたらバカが多い気がすんだよ。
>rollback(もしくはリソース開放)みたいなレスにクギを刺しとこうかと思ってね。
リソースは開放じゃなく解放だから、ちゃんとクギを刺しとこうかと思ってねｗ
あと、899,900も日本語がおかしいｗ
異常時の処理抜けにも便利よ
きちんと設計されてれば業務系の例外も綺麗に処理できるし、
各機能を実装する側も難しく考えないでルールに沿って例外投げるだけで
あとはお任せな形になるから、便利
ただ、きちんと設計ができてて、正しく使いきれてるプロジェクトはほっとんど見ないわｗ
分岐とループと関数さえわかってれば、同じ機能は作れてはしまうからな
きちんと設計されてれば業務系の例外も綺麗に処理できるし、
各機能を実装する側も難しく考えないでルールに沿って例外投げるだけで
あとはお任せな形になるから、便利
ただ、きちんと設計ができてて、正しく使いきれてるプロジェクトはほっとんど見ないわｗ
分岐とループと関数さえわかってれば、同じ機能は作れてはしまうからな
データベースの処理で異常が発生したとき、
いちいちdisconnectなんかしてると汎用性がないってだけ。
いろんな場合を考えないといけないから
コードが複雑になる。
いちいちdisconnectなんかしてると汎用性がないってだけ。
いろんな場合を考えないといけないから
コードが複雑になる。
下手に汎用性持たせようとして失敗してるパターン？
rollbackすればそこで確保されていた更新排他なんかも開放されるけど
新しくコネクションひらいたら、ものによったら全部終わるまでそのまま残ったりするよね
アホじゃね
新しくコネクションひらいたら、ものによったら全部終わるまでそのまま残ったりするよね
アホじゃね
>>901
例外やreturnなんかは、処理の入れ子を巻き戻してるだけだから
goto問題の範疇に入らない。言語設計側もそういう認識で作ってる。
そもそもgotoがダメって認識が、認識不足。
ダイクストラの本はタイトルはgoto不要とは書いてあるが、
中身は、サブルーチンの入れ子を無視したジャンプをするなという事が
書いてある。アセンブリコードを読むときも、処理の入れ子を守ってるコードと
無視したコードは読みやすさが段違いだ。よってgotoと同じようにジャンプするから
使わない方がいいという理解は間違ってる。
例外やreturnなんかは、処理の入れ子を巻き戻してるだけだから
goto問題の範疇に入らない。言語設計側もそういう認識で作ってる。
そもそもgotoがダメって認識が、認識不足。
ダイクストラの本はタイトルはgoto不要とは書いてあるが、
中身は、サブルーチンの入れ子を無視したジャンプをするなという事が
書いてある。アセンブリコードを読むときも、処理の入れ子を守ってるコードと
無視したコードは読みやすさが段違いだ。よってgotoと同じようにジャンプするから
使わない方がいいという理解は間違ってる。
VBではエラー処理にGoto使うのは通例だしなぁ
Try
Shell("hoge.exe", AppWinStyle.Hide, False)
Catch ex As FileNotFoundException
MsgBox("hoge.exe doesn't exist.")
End Try
Shell("hoge.exe", AppWinStyle.Hide, False)
Catch ex As FileNotFoundException
MsgBox("hoge.exe doesn't exist.")
End Try
Dim apppath As String = "hoge.exe"
Try
Shell(apppath, AppWinStyle.Hide, False)
Catch ex As FileNotFoundException
MsgBox(apppath & " doesn't exist.")
End Try
のほうが良かったかもしれない
Try
Shell(apppath, AppWinStyle.Hide, False)
Catch ex As FileNotFoundException
MsgBox(apppath & " doesn't exist.")
End Try
のほうが良かったかもしれない
>>911
はぁ？
「gotoが使わないほうが良い」というのが今の世の中の流れだ
俺が個人的な意見として「goto使うな」とか一言もいっていない
おｋ？
で、俺が言ってるのは、
全てのエラー処理を例外で書く理由はないといってる
例外の中に例外がネストしてるソースとか読みにくくてバカかと思ったから。
例外を使わなくちゃいけないっていうルールに縛られた結果がそういうソースになるんだろ
はぁ？
「gotoが使わないほうが良い」というのが今の世の中の流れだ
俺が個人的な意見として「goto使うな」とか一言もいっていない
おｋ？
で、俺が言ってるのは、
全てのエラー処理を例外で書く理由はないといってる
例外の中に例外がネストしてるソースとか読みにくくてバカかと思ったから。
例外を使わなくちゃいけないっていうルールに縛られた結果がそういうソースになるんだろ
>>919
へー、揚げ足取りたか無いけど、じゃあ日本語がおかしいんだな。
>例外って、ほんとに使いやすいの？ やたらあちこちに例外使ってる奴いるけど
>gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
>例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる
正しいって事だよ。ここだけ見ればお前はgotoの肯定はしていない事がわかる。
肯定してる事は全く伝わらん。
>全てのエラーを例外使うんじゃなく適材適所が良い気がする
最後のこの文をみても、gotoも肯定してる立場だと読み取れる要素は全くない。
人は存在する文脈から相手の考えを察しようとするんで、肯定に懐疑的な文章を読んで、
「否定を一言も言っていない」を脳内補完するヤツはいない。
へー、揚げ足取りたか無いけど、じゃあ日本語がおかしいんだな。
>例外って、ほんとに使いやすいの？ やたらあちこちに例外使ってる奴いるけど
>gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
>例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる
正しいって事だよ。ここだけ見ればお前はgotoの肯定はしていない事がわかる。
肯定してる事は全く伝わらん。
>全てのエラーを例外使うんじゃなく適材適所が良い気がする
最後のこの文をみても、gotoも肯定してる立場だと読み取れる要素は全くない。
人は存在する文脈から相手の考えを察しようとするんで、肯定に懐疑的な文章を読んで、
「否定を一言も言っていない」を脳内補完するヤツはいない。
リアルでひとと話すことがないようなニートに日本語力期待するお前が悪い
>>920
はぁ？ｗｗｗ
C言語で「「例外処理実装のためにgoto使うのが正しい」」って言っているのか
話になんねえｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
勝手に現場で一人それをかいてクビになれｗｗｗｗｗｗｗｗｗｗ
はぁ？ｗｗｗ
C言語で「「例外処理実装のためにgoto使うのが正しい」」って言っているのか
話になんねえｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
勝手に現場で一人それをかいてクビになれｗｗｗｗｗｗｗｗｗｗ
＞人は存在する文脈から相手の考えを察しようとするんで、肯定に懐疑的な文章を読んで、
＞「否定を一言も言っていない」を脳内補完するヤツはいない。
君は勝手に脳内保管しちゃったことを認めるべき
文章を読む力がなさ過ぎる････
人は存在する文脈から相手の考えを察しようとするんで（ｷﾘ)ww
＞「否定を一言も言っていない」を脳内補完するヤツはいない。
君は勝手に脳内保管しちゃったことを認めるべき
文章を読む力がなさ過ぎる････
人は存在する文脈から相手の考えを察しようとするんで（ｷﾘ)ww
人は存在する文脈から相手の考えを察しようとするんで（ｷﾘ)ww
人は存在する文脈から相手の考えを察しようとするんで（ｷﾘ)ww
人は存在する文脈から相手の考えを察しようとするんで（ｷﾘ)ww
人は存在する文脈から相手の考えを察しようとするんで（ｷﾘ)ww
そもそも、
＞ 例外やreturnなんかは、処理の入れ子を巻き戻してるだけだから
実装によるｗｗｗｗｗｗ おめーが見た言語のアセンブリコードでかたってんじゃねえよｗｗｗにわかｗｗｗｗｗｗ
＞言語設計側もそういう認識で作ってる。
意味不明ｗｗｗ妄想乙すぎるｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
＞ そもそもgotoがダメって認識が、認識不足。
>>901 を 100回よめ？
＞ダイクストラの本はタイトルはgoto不要とは書いてあるが、
そんな話してない
＞中身は、サブルーチンの入れ子を無視したジャンプをするなという事が
そんな話してない
＞書いてある。アセンブリコードを読むときも、処理の入れ子を守ってるコードと
そんな話してない
＞無視したコードは読みやすさが段違いだ。よってgotoと同じようにジャンプするから
そんな話してない
＞使わない方がいいという理解は間違ってる。
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
＞ 例外やreturnなんかは、処理の入れ子を巻き戻してるだけだから
実装によるｗｗｗｗｗｗ おめーが見た言語のアセンブリコードでかたってんじゃねえよｗｗｗにわかｗｗｗｗｗｗ
＞言語設計側もそういう認識で作ってる。
意味不明ｗｗｗ妄想乙すぎるｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
＞ そもそもgotoがダメって認識が、認識不足。
>>901 を 100回よめ？
＞ダイクストラの本はタイトルはgoto不要とは書いてあるが、
そんな話してない
＞中身は、サブルーチンの入れ子を無視したジャンプをするなという事が
そんな話してない
＞書いてある。アセンブリコードを読むときも、処理の入れ子を守ってるコードと
そんな話してない
＞無視したコードは読みやすさが段違いだ。よってgotoと同じようにジャンプするから
そんな話してない
＞使わない方がいいという理解は間違ってる。
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
そんな話してない そんな話してない そんな話してない そんな話してない そんな話してない
＞へー、揚げ足取りたか無いけど、じゃあ日本語がおかしいんだな。
既に>>911のレスからお前のレスは浮きまくりだよ
＞>例外って、ほんとに使いやすいの？ やたらあちこちに例外使ってる奴いるけど
＞>gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
＞>例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる
＞正しいって事だよ。ここだけ見ればお前はgotoの肯定はしていない事がわかる。
はあ？ｗｗｗ 俺は例外を否定してるんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗgotoの話してんのお前だけｗｗ
>全てのエラーを例外使うんじゃなく適材適所が良い気がする
＞最後のこの文をみても、gotoも肯定してる立場だと読み取れる要素は全くない。
＾＾；；；
＞人は存在する文脈から相手の考えを察しようとするんで、肯定に懐疑的な文章を読んで、
＞「否定を一言も言っていない」を脳内補完するヤツはいない。
ｷﾘｯ
また妄想で 人は〜 人は〜 って語っちゃって･･････ひどい妄想癖だね･･･ きっも
にわかに知識つけて（ｷﾘｯ）としながらレスつける相手を間違える奴をゴミと呼ぶ
最近じゃ殆ど誰も触ってなどいないアセンブラの話題を、こーんな場所でちらつかせるあたりがもう、
俺は細部まで知ってるぜ（ ← そんな気になっちゃってるだけ ） アピールっつうか･･･ 寒い奴だな････
人は存在する文脈から相手の考えを察しようとするんで（ｷﾘ)ww
既に>>911のレスからお前のレスは浮きまくりだよ
＞>例外って、ほんとに使いやすいの？ やたらあちこちに例外使ってる奴いるけど
＞>gotoは禁止してるくせに、例外によるジャンプは認めているってすっげー変な話
＞>例外を使うのが正しいっていうなら、C言語で例外処理実装の為にgoto使うのは正しいって事になる
＞正しいって事だよ。ここだけ見ればお前はgotoの肯定はしていない事がわかる。
はあ？ｗｗｗ 俺は例外を否定してるんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗgotoの話してんのお前だけｗｗ
>全てのエラーを例外使うんじゃなく適材適所が良い気がする
＞最後のこの文をみても、gotoも肯定してる立場だと読み取れる要素は全くない。
＾＾；；；
＞人は存在する文脈から相手の考えを察しようとするんで、肯定に懐疑的な文章を読んで、
＞「否定を一言も言っていない」を脳内補完するヤツはいない。
ｷﾘｯ
また妄想で 人は〜 人は〜 って語っちゃって･･････ひどい妄想癖だね･･･ きっも
にわかに知識つけて（ｷﾘｯ）としながらレスつける相手を間違える奴をゴミと呼ぶ
最近じゃ殆ど誰も触ってなどいないアセンブラの話題を、こーんな場所でちらつかせるあたりがもう、
俺は細部まで知ってるぜ（ ← そんな気になっちゃってるだけ ） アピールっつうか･･･ 寒い奴だな････
人は存在する文脈から相手の考えを察しようとするんで（ｷﾘ)ww
>920はキチガイにマジレスした責任をとって最後まで相手するように
やっぱりプログラマってゴミだったんだな･････････････････････
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
↑ 追加希望
３、知識もないのに知ったかぶってレス書き込み時に、単語単位（スレッドなど）から読解する事が出来なくなったプログラマ（『ゴミグラマ』も参照）。
４、ゴミグラマ（http://hibari.2ch.net/test/read.cgi/prog/1298059471/200）のこと
↑ 追加希望
３、知識もないのに知ったかぶってレス書き込み時に、単語単位（スレッドなど）から読解する事が出来なくなったプログラマ（『ゴミグラマ』も参照）。
４、ゴミグラマ（http://hibari.2ch.net/test/read.cgi/prog/1298059471/200）のこと
うはｗｗｗｗｗｗｗｗ レス番ミスったｗｗｗｗｗｗｗｗ
ここは社会から、例外処理される奴の吹き溜まりかｗ
finally
uyはユッケでも食って落ち着けｗ
おまえがそう思うんなら、そうなんだろう。
お前の中ではな。
中学で学年総シカトされたうえ、高校に進学できずニートになった
マジ○チくんと同じ臭いがする。何か親コロした上実家に火を放ちそうな
ファビョり具合だな。
お前の中ではな。
中学で学年総シカトされたうえ、高校に進学できずニートになった
マジ○チくんと同じ臭いがする。何か親コロした上実家に火を放ちそうな
ファビョり具合だな。
実際これでも譲歩してんのに
例 外 っ て な ん だ よ ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
環境（ OSと言語 ）がサポートしろバカｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
そんなゴミグラミングをしている君たちは本当に可愛そうだ
どこぞのハッカー1人が、まじめに、OS、言語を作ってくれたら
そんな問題から開放されるのに
ハッカーさんは自分のためにしか力を使わないからねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
金を詰まれてもやる気しないｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
Time is 金ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
例 外 っ て な ん だ よ ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
環境（ OSと言語 ）がサポートしろバカｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
そんなゴミグラミングをしている君たちは本当に可愛そうだ
どこぞのハッカー1人が、まじめに、OS、言語を作ってくれたら
そんな問題から開放されるのに
ハッカーさんは自分のためにしか力を使わないからねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
金を詰まれてもやる気しないｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
Time is 金ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
だからほんとプギャーｗｗｗｗ なんですよ
根底部分が、しょっぼい実装をしているせいで、 それを補うプログラミングをしちゃってる君ら････
よくやってられるね、幸せに仕事、プログラミング、プログラマ、したいやつは、気づいちゃいけない事実だけどさ
もしC言語のデリミタが ； が ；； だったらどうする？ｗｗｗｗｗｗｗｗｗｗ
そういう事だよｗｗｗｗｗｗｗ 俺が、ひとつ願いをかなえられるなら
C言語の ； を ；；；；； 規約にしてやろうかなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
；；；； ４つじゃコンパイルエラーｗｗｗ ；；；；； 5個つけないとダメｗｗｗｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗ
環境にｗｗｗｗｗｗｗｗｗｗ振り回されるｗｗｗｗｗｗｗｗｗ 君らｗｗｗｗｗｗｗｗｗｗｗ
そｗうｗいｗうｗこｗｗとｗだｗｗｗよｗｗｗｗｗｗｗｗ
根底部分が、しょっぼい実装をしているせいで、 それを補うプログラミングをしちゃってる君ら････
よくやってられるね、幸せに仕事、プログラミング、プログラマ、したいやつは、気づいちゃいけない事実だけどさ
もしC言語のデリミタが ； が ；； だったらどうする？ｗｗｗｗｗｗｗｗｗｗ
そういう事だよｗｗｗｗｗｗｗ 俺が、ひとつ願いをかなえられるなら
C言語の ； を ；；；；； 規約にしてやろうかなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
；；；； ４つじゃコンパイルエラーｗｗｗ ；；；；； 5個つけないとダメｗｗｗｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗ
環境にｗｗｗｗｗｗｗｗｗｗ振り回されるｗｗｗｗｗｗｗｗｗ 君らｗｗｗｗｗｗｗｗｗｗｗ
そｗうｗいｗうｗこｗｗとｗだｗｗｗよｗｗｗｗｗｗｗｗ
バカが、さわんじゃねーよ…
え？
┌──┐ ー-- ＿|＿_ ヽ ┌┐ ┌┐ ──- ー-- ＿|＿_ ヽ
lニニニ| -─┐ | | ＼ 匚l . 匚| -─┐ | | ＼
└┬┬┘ ／ ﾉ | | ｜ | ‐Ｅﾖ￣｜ ／ ﾉ | | |
ノ |＿ﾉ ／⌒l＿ ＜ﾌ＼ レ | ┴┼ ｜ （＿＿＿ ／⌒l＿ ＜ﾌ＼ レ
┌──┐ ー-- ＿|＿_ ヽ ┌┐ ┌┐ ──- ー-- ＿|＿_ ヽ
lニニニ| -─┐ | | ＼ 匚l . 匚| -─┐ | | ＼
└┬┬┘ ／ ﾉ | | ｜ | ‐Ｅﾖ￣｜ ／ ﾉ | | |
ノ |＿ﾉ ／⌒l＿ ＜ﾌ＼ レ | ┴┼ ｜ （＿＿＿ ／⌒l＿ ＜ﾌ＼ レ
こいつは速攻でNGNameに登録できるから別に害はないだろ
>>939
死ねよ＾＾
死ねよ＾＾
またレス番飛んでる
gotoを使う場合は、頑張ればできる。
例外を使えば、簡単にできる。
できるできないの話はしていない。
どちらでもできる。当たり前。
簡単かどうかの話をしている。
例外を使えば、簡単にできる。
できるできないの話はしていない。
どちらでもできる。当たり前。
簡単かどうかの話をしている。
gotoと一緒くたにしてる人まだいたのね
理解できないバカが例外はgotoとおなじで
どこに行くかわからないとかほざいてるのたまに聞くけど、ネタだと思ってたわｗ
理解できないバカが例外はgotoとおなじで
どこに行くかわからないとかほざいてるのたまに聞くけど、ネタだと思ってたわｗ
come fromだよなw
例外と比べるなら、クロージャのほうが近い。
gotoと比べるなら、breakやcontinueのほうが近い。
gotoと比べるなら、breakやcontinueのほうが近い。
俺が例外。
単純なロジックしか書いていないからわからないんだろうな･･･
まぁ、「例外」っていう概念に、俺がそこまでの負荷チェックをしてる事が間違っているのかな
未完成概念でも、現在君らがやってるプログラミング上では
なんら問題なく記述できるんなら、好きにかくといいよ
単純なロジックしか書いていないからわからないんだろうな･･･
まぁ、「例外」っていう概念に、俺がそこまでの負荷チェックをしてる事が間違っているのかな
未完成概念でも、現在君らがやってるプログラミング上では
なんら問題なく記述できるんなら、好きにかくといいよ
例外はハンドラ設定はほぼノーコスト。
こうやって、
授業料もらっているわけでもなく、無償で忠告を与えているにもかかわらず
それを聞かないからいつまでたってもゴミなんだよねお前ら
授業料もらっているわけでもなく、無償で忠告を与えているにもかかわらず
それを聞かないからいつまでたってもゴミなんだよねお前ら
ゴミニートには税金経由で金恵んでやってるじゃないか
感謝しろよ
感謝しろよ
税金経由だと、中抜きされるから
直接金をくれなイカ
直接金をくれなイカ
ニートかよｗ
コンサルやってる俺が書いてやるよ。
例外はメソッドの事後条件を満たせない場合にのみスローしろ。
メソッド内でnullチェックやってようが、他のチェックやっていようが事後条件を満たせない場合にだけスローしろ。
呼び出し元は呼び出し先がどんなチェックしてるか知っている必要はない。
呼び出し元が予期してないから例外なのであって、呼び出し元で例外を意識して処理させるような設計は糞。
つまり検査例外なんてものはもっての他だ。
そんなものがスローされる条件がわかるなら、最初から投げられないように呼ぶほうがマシ。
例外はメソッドの事後条件を満たせない場合にのみスローしろ。
メソッド内でnullチェックやってようが、他のチェックやっていようが事後条件を満たせない場合にだけスローしろ。
呼び出し元は呼び出し先がどんなチェックしてるか知っている必要はない。
呼び出し元が予期してないから例外なのであって、呼び出し元で例外を意識して処理させるような設計は糞。
つまり検査例外なんてものはもっての他だ。
そんなものがスローされる条件がわかるなら、最初から投げられないように呼ぶほうがマシ。
DbC！DbC！
例外を語るヤツは禿の論文読んでるよな。
まさか基礎論も知らずに偉そうに講釈タレてるなんて事ないよな。当然。
Exception Safety: Concepts and Techniques
http://www2.research.att.com/~bs/except.pdf
まさか基礎論も知らずに偉そうに講釈タレてるなんて事ないよな。当然。
Exception Safety: Concepts and Techniques
http://www2.research.att.com/~bs/except.pdf
>>956
なんて答えて欲しいんだ？
なんて答えて欲しいんだ？
>>956
自分の言葉で語れないならハナから書き込むなよ
自分の言葉で語れないならハナから書き込むなよ
>>953
呼び出し元が予期してないのが例外ではなく
呼ばれた処理が継続できない状態だと判断したからの例外だろ
呼び元が何かを意識するような、呼び元依存のメソッド設計はアホじゃね
そういうの多いけど
呼ぶ側が例外処理をするのめんどくさい、っていう呼び元視点だとそうなるのかもしれないけど
まずその視点が間違ってると思うんだが
大体入力された値のチェックなんかで発生させるような例外は、
チェック漏れ=ただの不具合なんだし、RuntimeExceptionとかErrorなりアサーションなりでやればいいわけで
検査例外からは除外されてるのが普通だし、呼び元が補足意識しないといけないわけじゃないような
検査例外は throws Exception する馬鹿処理が1個でも混じってるだけで破綻するし
きちんとjavadocが書ける奴がいないと、throwsだけあってもぶっちゃけ意味がないから
コンパイル通らなくなる制限は邪魔以外の何者でもないと思うけどな
呼び出し元が予期してないのが例外ではなく
呼ばれた処理が継続できない状態だと判断したからの例外だろ
呼び元が何かを意識するような、呼び元依存のメソッド設計はアホじゃね
そういうの多いけど
呼ぶ側が例外処理をするのめんどくさい、っていう呼び元視点だとそうなるのかもしれないけど
まずその視点が間違ってると思うんだが
大体入力された値のチェックなんかで発生させるような例外は、
チェック漏れ=ただの不具合なんだし、RuntimeExceptionとかErrorなりアサーションなりでやればいいわけで
検査例外からは除外されてるのが普通だし、呼び元が補足意識しないといけないわけじゃないような
検査例外は throws Exception する馬鹿処理が1個でも混じってるだけで破綻するし
きちんとjavadocが書ける奴がいないと、throwsだけあってもぶっちゃけ意味がないから
コンパイル通らなくなる制限は邪魔以外の何者でもないと思うけどな
呼び出し元が予期するのは
例外のあるなしであって
例外の種類は原則として予期しない。
呼び出し元は、すべての呼び出しで
例外が発生する可能性があるという前提で作る。
だけど、例外の種類は問わない。
どんな種類の例外がきても大丈夫なようにつくる。
だから検査例外は必要ない。
例外のあるなしであって
例外の種類は原則として予期しない。
呼び出し元は、すべての呼び出しで
例外が発生する可能性があるという前提で作る。
だけど、例外の種類は問わない。
どんな種類の例外がきても大丈夫なようにつくる。
だから検査例外は必要ない。
この間 BOSS2（ドラマ）の中で犯人のコンピュータにハッキングするところで
ソースコードが表示されてて goto ってのがあったような気がする
ソースコードが表示されてて goto ってのがあったような気がする
>>960
それじゃ回復できるもんも回復できねぇだろボケェ
ディスク容量足りなくて例外発生したなら、別のディスクに書き込むか、
ユーザーに書き込み先を指定させる事ができるが、
メモリーが足りなくて例外発生してたなら、そんな事してもどうにもならん。
先に開放できるメモリーの開放が必要になる。
例外の種類を無視したらこういう区別ができねぇだろ。
それじゃ回復できるもんも回復できねぇだろボケェ
ディスク容量足りなくて例外発生したなら、別のディスクに書き込むか、
ユーザーに書き込み先を指定させる事ができるが、
メモリーが足りなくて例外発生してたなら、そんな事してもどうにもならん。
先に開放できるメモリーの開放が必要になる。
例外の種類を無視したらこういう区別ができねぇだろ。
>>963
チェック例外で回復できない例外って何？
あと、本格的に例外処理しないにしても、
例外を受け取ったコールスタックで判断できる
情報を追加して例外を投げなおすぐらいは
必須だと思うけど。(例えば、writeでPermissonErrorが
発生したら、今開いているファイル名を負荷した
PermissionErrorを作り直して投げる)
チェック例外で回復できない例外って何？
あと、本格的に例外処理しないにしても、
例外を受け取ったコールスタックで判断できる
情報を追加して例外を投げなおすぐらいは
必須だと思うけど。(例えば、writeでPermissonErrorが
発生したら、今開いているファイル名を負荷した
PermissionErrorを作り直して投げる)
>>960
そりゃ全ての処理の大元なんかが意識すればいいことだろ
だが、んなとこでできる復旧なんて、最初からやり直しだとかそういうレベルの
どうしても手に負えなかったような例外だけだっつー
必要のない場所でまで catch (Exception e) とかやってたらただの馬鹿だぞ？
予期せぬ不具合までもみ消しを起こす可能性生む糞コード
だいたい、検査例外って、回復手段はいくつか想定できるが、
どうしたいかは呼び元によるような場合に発生すんのが殆どじゃねーか
どんな例外が起こるか知らないで、どうするんだっていう
そりゃ、最終的にはどんな例外でも復旧すべきなのは、言うまでもなく当たり前の話だけど
んなこと意識するのは大元のほう担当する奴だけ
そういうのやる奴は最低限このあたりの事くらい理解してるだろうから、
960みたいな馬鹿発言しねーと思うんだけどな
…もしかして、一人で全部作るような小規模なプログラムの話してたのかな？
まーあれだよ
処理の端々で全部の例外キャッチするようなコードを書く奴が絶えないのも
throws Exceptionってかかれた糞メソッドを生み出す馬鹿がいるせいだとは思うけどな
んなことするくらいなら、最初から検査例外のない言語で作れよって言いたいわー
そりゃ全ての処理の大元なんかが意識すればいいことだろ
だが、んなとこでできる復旧なんて、最初からやり直しだとかそういうレベルの
どうしても手に負えなかったような例外だけだっつー
必要のない場所でまで catch (Exception e) とかやってたらただの馬鹿だぞ？
予期せぬ不具合までもみ消しを起こす可能性生む糞コード
だいたい、検査例外って、回復手段はいくつか想定できるが、
どうしたいかは呼び元によるような場合に発生すんのが殆どじゃねーか
どんな例外が起こるか知らないで、どうするんだっていう
そりゃ、最終的にはどんな例外でも復旧すべきなのは、言うまでもなく当たり前の話だけど
んなこと意識するのは大元のほう担当する奴だけ
そういうのやる奴は最低限このあたりの事くらい理解してるだろうから、
960みたいな馬鹿発言しねーと思うんだけどな
…もしかして、一人で全部作るような小規模なプログラムの話してたのかな？
まーあれだよ
処理の端々で全部の例外キャッチするようなコードを書く奴が絶えないのも
throws Exceptionってかかれた糞メソッドを生み出す馬鹿がいるせいだとは思うけどな
んなことするくらいなら、最初から検査例外のない言語で作れよって言いたいわー
>>966
ぞんざいな職場だな。派遣？
仕様に詳細が無くとも例外の発生原因はメッセージに出すぞ。
レビュー時の指摘事項になってる。
揉み消したり、例外メッセージを
そのままでだしたりしたら信用に関わるからな。
あと外部設計に関わらない範囲なら現場の判断で、
できるだけリカバリーを取る。
ぞんざいな職場だな。派遣？
仕様に詳細が無くとも例外の発生原因はメッセージに出すぞ。
レビュー時の指摘事項になってる。
揉み消したり、例外メッセージを
そのままでだしたりしたら信用に関わるからな。
あと外部設計に関わらない範囲なら現場の判断で、
できるだけリカバリーを取る。
横からだが、点数をつけてやるよ。
設計能力は>>966が６０点 >>967が３０点ぐらいだな。
今回は甘めの点数にした。正直967は初心者クラスだな。
966も967相手だからかなり点数を甘くしただけだから。
設計能力は>>966が６０点 >>967が３０点ぐらいだな。
今回は甘めの点数にした。正直967は初心者クラスだな。
966も967相手だからかなり点数を甘くしただけだから。
>>967
> 仕様に詳細が無くとも例外の発生原因はメッセージに出すぞ。
だからそういうこと。
仕様に詳細が無い物。それは無限にある。
書いてあるものは数が限られているが、
それ以外は数が限定できない。
そういう未知のものに対応するコードが書いてあるのなら、
チェック例外であっても基本的にはそのコードで対応できるはず。
だから、特別扱いしたい例外だけ捉えれば済むので
チェック例外の意味がないわけ。
> 仕様に詳細が無くとも例外の発生原因はメッセージに出すぞ。
だからそういうこと。
仕様に詳細が無い物。それは無限にある。
書いてあるものは数が限られているが、
それ以外は数が限定できない。
そういう未知のものに対応するコードが書いてあるのなら、
チェック例外であっても基本的にはそのコードで対応できるはず。
だから、特別扱いしたい例外だけ捉えれば済むので
チェック例外の意味がないわけ。
例外に頼りすぎなんだよ
緊急地震速報 毎日のように垂れ流されたら、なにが緊急なのかわけわかんなくなるだろ
例外ってどれが例外だよ
緊急地震速報 毎日のように垂れ流されたら、なにが緊急なのかわけわかんなくなるだろ
例外ってどれが例外だよ
>>969
発生原因は、getMessage()やらmessage()やらで取れる文字列の事じゃないんだけどな。
日本語でかつ、ユーザーが見て何をどう変えればいいか判断できる内容だ。
例えば、「ホストに繋げませんでした」じゃユーザーはどうしようもない。
「ホストに接続できませんでした。
詳細：XXXX番ポートを使用できず接続できませんでした。
ファイアウォールやOSの設定で、XXXX番ポートの使用が
制限されていないかご確認下さい。」
というようなできるだけ対処可能な情報提供が必要。
でこの情報を出すには、例外に、ポートが原因だという型情報と、
ポートの何番が問題になったかを載せておく必要がある。
とりあえず戻り値を-1で返して、例外情報をGetLastErrorみたいな
形で返すならともかく、タダのエラーコードじゃユーザーは、
「またどこがおかしいのか調べなきゃいけないのか、
問い合わせるの面倒くせぇ、今度の発注先変えるか」つう事になる。
発生原因は、getMessage()やらmessage()やらで取れる文字列の事じゃないんだけどな。
日本語でかつ、ユーザーが見て何をどう変えればいいか判断できる内容だ。
例えば、「ホストに繋げませんでした」じゃユーザーはどうしようもない。
「ホストに接続できませんでした。
詳細：XXXX番ポートを使用できず接続できませんでした。
ファイアウォールやOSの設定で、XXXX番ポートの使用が
制限されていないかご確認下さい。」
というようなできるだけ対処可能な情報提供が必要。
でこの情報を出すには、例外に、ポートが原因だという型情報と、
ポートの何番が問題になったかを載せておく必要がある。
とりあえず戻り値を-1で返して、例外情報をGetLastErrorみたいな
形で返すならともかく、タダのエラーコードじゃユーザーは、
「またどこがおかしいのか調べなきゃいけないのか、
問い合わせるの面倒くせぇ、今度の発注先変えるか」つう事になる。
>>972
だからなんなんだよ？
例外を使うプログラミングに置いて
そういう情報提供をするのは例外を送信する側の仕事。
もし標準の情報が物足りないと判断したら、
その時は特別扱いして、例外をキャッチし情報を追加し、
また例外として再送出する。
すべての例外に詳しい情報を作成するのは開発工数的に無理。
つまり「こういう場合には詳しい情報を出す」という仕様が必要
仕様が暗黙の了解で済むような、ちゃらんぽらんな会社ならご愁傷さま。
だから、
デフォルトではなにもしない。（メッセージを追加したいなどの）
特別扱いしたい例外だけ捉えれば済む。という全く同じ結論になる。
だからなんなんだよ？
例外を使うプログラミングに置いて
そういう情報提供をするのは例外を送信する側の仕事。
もし標準の情報が物足りないと判断したら、
その時は特別扱いして、例外をキャッチし情報を追加し、
また例外として再送出する。
すべての例外に詳しい情報を作成するのは開発工数的に無理。
つまり「こういう場合には詳しい情報を出す」という仕様が必要
仕様が暗黙の了解で済むような、ちゃらんぽらんな会社ならご愁傷さま。
だから、
デフォルトではなにもしない。（メッセージを追加したいなどの）
特別扱いしたい例外だけ捉えれば済む。という全く同じ結論になる。
べつによいのですよ？
わたくしの擁護をなさらなくても
じぶんのただしさはじぶんが一番よくしっております
それとも、uy勢力に加わる?
自信があるのなら、わざわざそんな負け惜しみを言わなくていいじゃないｗ
なんか流れがチェック例外の話から脱線してきてるようにも思えるけど、
チェック例外で回復できない例外は基本的にないでしょ。
外設に影響しない部分は、内部でルール決めて処理するか、仕様漏れを指摘して外設に追記依頼するのが普通だしな。
仕様にないものは回復できないって、そりゃ仕様バグだ。
基本設計だか詳細設計だかでの考慮漏れ、リリース前には修正するだろ。
>>969
> そういう未知のものに対応するコードが書いてあるのなら、
> チェック例外であっても基本的にはそのコードで対応できるはず。
そういう未知のものに対応するコードを書くような場所で補足しても、既に処理抜けて手遅れだろ。
もっと手前の発生場所の近くで補足して、回復するか、処理済の例外としてラップするのが普通。
それともあれか。
複数のメソッドに catch (Exception e)、handleException(e)みたいなコード埋め込むのが
正しいやり方だって主張したいん？
チェック例外は戻り値のチェックと同じ話だよ。
戻り値のフラグを意図的に無視したのか、チェック漏れかがわからない。
しかし例外なら無視はできないから必ずコードで表現する必要がある。
チェック例外の場合は、特別扱いしたくないものだから補足しなかったのか、
補足わすれたバグなのかがコードから判断つかないから、補足を必須にして、
無視したいなら無視したことがわかるようコーディングしろ。
それがチェック例外の目的でしょ。
まー、チェック例外は"全員がきちんと使っていれば"、補足漏れがなくなって便利ってだけ。
実際は、きちんと使えない馬鹿が1人混ざっただけで全部破綻するからいらない、っていう話はちょくちょく出るけどなｗ
>>967
悲しいことに、そういうぞんざいな職場は腐るほどあるよ。
っていうかまともにやってるとこを見かけるほうが割りと稀だったりするわ…。
チェック例外で回復できない例外は基本的にないでしょ。
外設に影響しない部分は、内部でルール決めて処理するか、仕様漏れを指摘して外設に追記依頼するのが普通だしな。
仕様にないものは回復できないって、そりゃ仕様バグだ。
基本設計だか詳細設計だかでの考慮漏れ、リリース前には修正するだろ。
>>969
> そういう未知のものに対応するコードが書いてあるのなら、
> チェック例外であっても基本的にはそのコードで対応できるはず。
そういう未知のものに対応するコードを書くような場所で補足しても、既に処理抜けて手遅れだろ。
もっと手前の発生場所の近くで補足して、回復するか、処理済の例外としてラップするのが普通。
それともあれか。
複数のメソッドに catch (Exception e)、handleException(e)みたいなコード埋め込むのが
正しいやり方だって主張したいん？
チェック例外は戻り値のチェックと同じ話だよ。
戻り値のフラグを意図的に無視したのか、チェック漏れかがわからない。
しかし例外なら無視はできないから必ずコードで表現する必要がある。
チェック例外の場合は、特別扱いしたくないものだから補足しなかったのか、
補足わすれたバグなのかがコードから判断つかないから、補足を必須にして、
無視したいなら無視したことがわかるようコーディングしろ。
それがチェック例外の目的でしょ。
まー、チェック例外は"全員がきちんと使っていれば"、補足漏れがなくなって便利ってだけ。
実際は、きちんと使えない馬鹿が1人混ざっただけで全部破綻するからいらない、っていう話はちょくちょく出るけどなｗ
>>967
悲しいことに、そういうぞんざいな職場は腐るほどあるよ。
っていうかまともにやってるとこを見かけるほうが割りと稀だったりするわ…。
> チェック例外で回復できない例外は基本的にないでしょ。
回復できないかどうかという、可能かどうかという話しは関係なく、
実際に回復するかどうかの話。
回復可能であっても回復しないこともある。
それは仕様による。すべてのチェック例外を回復させるわけじゃない。
また非チェック例外でも回復させることもある。
このように、チェック例外と非チェック例外で
区別することが何も無いのだから
チェック例外の必要性がない。
回復できないかどうかという、可能かどうかという話しは関係なく、
実際に回復するかどうかの話。
回復可能であっても回復しないこともある。
それは仕様による。すべてのチェック例外を回復させるわけじゃない。
また非チェック例外でも回復させることもある。
このように、チェック例外と非チェック例外で
区別することが何も無いのだから
チェック例外の必要性がない。
ライブラリのようなものが、 チェック例外を発生させるのが
間違いなのでは？ つまりJavaの標準ライブラリなどは
チェック例外を発生してはいけない。
チェック例外はビジネスロジックを作る側が発生させる物。
ライブラリを使用している側が、
ライブラリが発生した非チェック例外を捉えて、
チェック例外に変換して、再発生させるよう形に
限定して使ううべき。
チェック例外は、そのアプリ専用の例外となる。
ライブラリを使用したライブラリは、ライブラリなので
もちろんチェック例外を使ったらいけません。
間違いなのでは？ つまりJavaの標準ライブラリなどは
チェック例外を発生してはいけない。
チェック例外はビジネスロジックを作る側が発生させる物。
ライブラリを使用している側が、
ライブラリが発生した非チェック例外を捉えて、
チェック例外に変換して、再発生させるよう形に
限定して使ううべき。
チェック例外は、そのアプリ専用の例外となる。
ライブラリを使用したライブラリは、ライブラリなので
もちろんチェック例外を使ったらいけません。
>>978
try-catch書き忘れてコンパイラに怒られた経験は？
コンパイラに指摘されて、処理し忘れた事に気づくことは多々ある。
例外処理を入れなきゃならないとわかってていても、
コード書いた時は忘れてる事が多い。コンパイル時の
型チェックによって構文ミスに気づくのと同じことだ。
まぁ、いまどきの子はEclipseがあるしコマンドライン中心で
コード書いた事無いから解らんのだろうけど。
それでもチェック例外で例外処理を書き忘れないという恩恵には
与れているはずだが。
try-catch書き忘れてコンパイラに怒られた経験は？
コンパイラに指摘されて、処理し忘れた事に気づくことは多々ある。
例外処理を入れなきゃならないとわかってていても、
コード書いた時は忘れてる事が多い。コンパイル時の
型チェックによって構文ミスに気づくのと同じことだ。
まぁ、いまどきの子はEclipseがあるしコマンドライン中心で
コード書いた事無いから解らんのだろうけど。
それでもチェック例外で例外処理を書き忘れないという恩恵には
与れているはずだが。
>>979
えとな、コンパイラに怒られて書くコードが
すべて同じになるんだよ。
エラーを再送出するという同じコードに。
このエラーの時は特別な処理をしたいなって思うときは
コードを書くのを忘れない。
それ以外はすべて同じコード。
チェック例外は単にテンプレを書かされてるだけ。
それに一体何の意味があるんだよ。
えとな、コンパイラに怒られて書くコードが
すべて同じになるんだよ。
エラーを再送出するという同じコードに。
このエラーの時は特別な処理をしたいなって思うときは
コードを書くのを忘れない。
それ以外はすべて同じコード。
チェック例外は単にテンプレを書かされてるだけ。
それに一体何の意味があるんだよ。
例外仕様に追記って何だ？
関数の所に送出する例外を付け加えるアレか？
あれはいかん。関数のシグネチャが変わってしまう。
インターフェースには送出する例外を書いてないとき
実装だけを変えることができない。当たり前だが。
だから汎用的に使えるのはcatchで別の例外に置き換えるやりかただが、
わざわざ別の例外に変更するのは言うまでもなく面倒
どうせ自分の例外にラップして、再送出するという
同じコードを書くだけになるんだから。
関数の所に送出する例外を付け加えるアレか？
あれはいかん。関数のシグネチャが変わってしまう。
インターフェースには送出する例外を書いてないとき
実装だけを変えることができない。当たり前だが。
だから汎用的に使えるのはcatchで別の例外に置き換えるやりかただが、
わざわざ別の例外に変更するのは言うまでもなく面倒
どうせ自分の例外にラップして、再送出するという
同じコードを書くだけになるんだから。
>>982
例外仕様の仕組みをよく知らないだろ。
例えIOExceptionを例外仕様に書いてあっても、
IOExceptionしかcatchできない訳じゃない。
IOExceptionを継承しているクラスの名前をcatchに
書いてやれば例外仕様に書いてない例外を処理する事ができる。
i
例外仕様の仕組みをよく知らないだろ。
例えIOExceptionを例外仕様に書いてあっても、
IOExceptionしかcatchできない訳じゃない。
IOExceptionを継承しているクラスの名前をcatchに
書いてやれば例外仕様に書いてない例外を処理する事ができる。
i
>>982
メソッドの例外仕様には機能的なカテゴリを表す例外クラスを
書くのであって、具体的な例外クラスの名前を書くんじゃない。
だからもっとも抽象的な例外カテゴリをinterfaceに追記している限り、
interfaceのメソッドに書いてある例外仕様を書き換えなきゃならんなんて
事にはならない。
メソッドの例外仕様には機能的なカテゴリを表す例外クラスを
書くのであって、具体的な例外クラスの名前を書くんじゃない。
だからもっとも抽象的な例外カテゴリをinterfaceに追記している限り、
interfaceのメソッドに書いてある例外仕様を書き換えなきゃならんなんて
事にはならない。
> 抽象的な例外カテゴリをinterfaceに追記している限り
だから全部にExceptionを書いた状態であればいい。
だから全部にExceptionを書いた状態であればいい。
関数仕様にない例外が発生したという例外を発生させればいいだけ。
987 ： 忍法帖【Lv=1,xxxP】 !：2011/05/29(日) 11:31:21.86
UnexpectedExceptionThrownExceptionThrownExceptionThrownException...
結局否定してる理由は、「面倒くさい」ってことなんでしょ。
面倒だからって理由で、意図が判断し辛いコードを書いて、
面倒だからって理由で、その意図をコメントとしては残さないやつが必ずいるから
判断し辛いコードにならないように、コーディングレベルで意図が明確になるようにする仕組みなんだから、
検査例外の目的は果たせてるってことじゃん。
面倒だからって理由で、意図が判断し辛いコードを書いて、
面倒だからって理由で、その意図をコメントとしては残さないやつが必ずいるから
判断し辛いコードにならないように、コーディングレベルで意図が明確になるようにする仕組みなんだから、
検査例外の目的は果たせてるってことじゃん。
違うな。
面倒なことをしても何のメリットもないのが問題。
結局コメントを書けばいいだけの話で
検査例外の必要性がない。
面倒なことをしても何のメリットもないのが問題。
結局コメントを書けばいいだけの話で
検査例外の必要性がない。
で>>979へ戻る訳か。
991 ：仕様書無しさん 忍法帖【Lv=3,xxxP】 ：2011/05/29(日) 12:20:56.22
>>989
ちがわねーよ。本当に馬鹿なのか？
コメントは強制じゃないからルールを守らせるのは無理。
Javaの根底に再利用ができるコードってのがあるから、そういう面倒な仕組みになったんでしょ。
文句垂れるならそんな言語を選択しなけりゃ良いだけで、Javaを使う以上、言語仕様くらい守っとけ。
ちがわねーよ。本当に馬鹿なのか？
コメントは強制じゃないからルールを守らせるのは無理。
Javaの根底に再利用ができるコードってのがあるから、そういう面倒な仕組みになったんでしょ。
文句垂れるならそんな言語を選択しなけりゃ良いだけで、Javaを使う以上、言語仕様くらい守っとけ。
Javaの言語仕様に文句を付けている人がいるからこそ
Javaが進化し続けているというのを忘れるな。
Javaが進化し続けているというのを忘れるな。
javaの言語自体に文句はねーよ
でもプログラム組む前の前準備や周辺機器（ライブラリ？）は全環境中最悪だと言える
Eclipseお前だよ
でもプログラム組む前の前準備や周辺機器（ライブラリ？）は全環境中最悪だと言える
Eclipseお前だよ
Javaで有名な人も検査例外を否定していたよね。
まー馬鹿が紛れ込んでて、どっかになに投げるかわからないからって
throws Exception って書かれてしまっていた案件はもう手遅れ状態になるし
他社製ライブラリとかがそういうことしてたりすると、検査例外の仕組みがほぼ死ぬから
そういう意味ではやっぱ邪魔だなとは思うよ
コンパイラ設定で警告にするかエラーにするか選べるとかあればよかったかもしれないな
つっても今やってるプロジェクトのソースは、警告だけで10k越えてて、
警告が全く意味なしてないのだけれどな/ ,' 3 `ヽｰっ
throws Exception って書かれてしまっていた案件はもう手遅れ状態になるし
他社製ライブラリとかがそういうことしてたりすると、検査例外の仕組みがほぼ死ぬから
そういう意味ではやっぱ邪魔だなとは思うよ
コンパイラ設定で警告にするかエラーにするか選べるとかあればよかったかもしれないな
つっても今やってるプロジェクトのソースは、警告だけで10k越えてて、
警告が全く意味なしてないのだけれどな/ ,' 3 `ヽｰっ
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。