例外を正しく使えないプログラマ多いね。 その5
|
|
|
2 ：仕様書無しさん：2011/02/06(日) 16:27:04
まだやるの?
3 ：仕様書無しさん：2011/02/06(日) 16:28:36
#include <iostream>
using namespace std;
int main() {
try {
throw (void*)"ﾌﾟｷﾞｬｰ！";
}
catch(void*) { cout << "void*" << endl; }
catch(const char *) {cout << "char*" << endl;}
}
void *にキャストしないとたしかにキャッチしないg++を確認
using namespace std;
int main() {
try {
throw (void*)"ﾌﾟｷﾞｬｰ！";
}
catch(void*) { cout << "void*" << endl; }
catch(const char *) {cout << "char*" << endl;}
}
void *にキャストしないとたしかにキャッチしないg++を確認
4 ：仕様書無しさん：2011/02/06(日) 16:30:51
>>1よ C++で正しく使う例(シンプルでいいから)を色々なデータ型で示せ
それをしないで猿とか言うな。なっ
それをしないで猿とか言うな。なっ
今度は「戻り値でエラーを返す方法を正しく知らないプログラマ多いね」にして欲しかったな。
戻り値でエラーを返すには様々な問題点がある。
一番の問題点は、戻り値に正常な戻り値とエラー用の戻り値を
うまく混ぜるにはどうするか悩むという問題点だ。
戻り値でエラーを返すには様々な問題点がある。
一番の問題点は、戻り値に正常な戻り値とエラー用の戻り値を
うまく混ぜるにはどうするか悩むという問題点だ。
6 ：仕様書無しさん：2011/02/06(日) 16:35:03
>>5よ
あほなこと言うな。たとえばMySQLのAPIの一例
戻り値 摘要
0 データがアプリケーションデータバッファーにフェッチされた場合、成功
1 エラーが発生しました。エラーコードとエラーメッセージは、mysql_stmt_errno()およびmysql_stmt_error()を呼び出すことによって取得することができます。
MYSQL_NO_DATA もう列/データは存在しない
MYSQL_DATA_TRUNCATED データの切り捨てが発生
あほなこと言うな。たとえばMySQLのAPIの一例
戻り値 摘要
0 データがアプリケーションデータバッファーにフェッチされた場合、成功
1 エラーが発生しました。エラーコードとエラーメッセージは、mysql_stmt_errno()およびmysql_stmt_error()を呼び出すことによって取得することができます。
MYSQL_NO_DATA もう列/データは存在しない
MYSQL_DATA_TRUNCATED データの切り捨てが発生
7 ：仕様書無しさん：2011/02/06(日) 16:36:10
エラーコードをチェックするのも
catchを重ねて書くのも同じだろう。意味の無いこと言うな
catchを重ねて書くのも同じだろう。意味の無いこと言うな
catchはクソ長ったらしいし。ネストが増えるし。
リターンエラー無視が出来ない。
リターンエラー無視が出来ない。
例外を使わない＝戻り値を使うとは限らないからな。
大域変数やスレッドローカルな変数にエラーコードを入れるという手もある。
大域変数やスレッドローカルな変数にエラーコードを入れるという手もある。
10 ：仕様書無しさん：2011/02/06(日) 16:41:44
なんで>>6に限定するんだ?
12 ：仕様書無しさん：2011/02/06(日) 16:43:47
13 ：仕様書無しさん：2011/02/06(日) 16:44:53
たたき台不足だな。
エラーが発生したらどこかに記録するだけで処理はそのまま継続するってのは意外と便利。
トライ＆エラーで作るならその場で止まってもらった方が便利。
１，数段上に戻って、中間処理をパスできる場合。例外が便利。
上にほうに集約的に戻れれば戻れるほど、利便性がます。
例外は必ず何処かでキャッチできるので、エラー無視がない。
２．エラーだからと言って、上に飛んでは困る処理が多い場合。
例外だと助長性が増える。コーディング量が増えるだけバグの温床になる。
また、単純な無視が出来ないため、さらに助長性が増える。
この場合、例外の欠点が増加する。
以上！
上にほうに集約的に戻れれば戻れるほど、利便性がます。
例外は必ず何処かでキャッチできるので、エラー無視がない。
２．エラーだからと言って、上に飛んでは困る処理が多い場合。
例外だと助長性が増える。コーディング量が増えるだけバグの温床になる。
また、単純な無視が出来ないため、さらに助長性が増える。
この場合、例外の欠点が増加する。
以上！
18 ：仕様書無しさん：2011/02/06(日) 17:09:45
また立てたのか。 どんだけ例外好きなんだオマエラ。
例えば"○○.txt"というファイルが存在することが前提、あるいは保証されるなら
open系の関数呼び出し時にFileNotFound系のエラー処理は一切書かないよ。
通常のnewやmalocで「メモリが足りない」系のエラーに対処しないのと同じようにね。
それは例外だろうと戻り値だろうと同じ。
open系の関数呼び出し時にFileNotFound系のエラー処理は一切書かないよ。
通常のnewやmalocで「メモリが足りない」系のエラーに対処しないのと同じようにね。
それは例外だろうと戻り値だろうと同じ。
>例えば"○○.txt"というファイルが存在することが前提、あるいは保証されるなら
が仕様書で保証されていても、それでシステムが転けたら。
きっとお前のせいにされるだろう。間違いなく無能がプログラマとして。
が仕様書で保証されていても、それでシステムが転けたら。
きっとお前のせいにされるだろう。間違いなく無能がプログラマとして。
「無能」も追加されちまった；
>>6
お前、>>5に何も反論してないじゃん。
お前が持ってきたそれ、戻り値はエラー値専用にしか使ってないだろ。
まぜるなって話をしているんだから、
正常な戻り値とエラー値を混ぜてる例を持って来いよ。
お前、>>5に何も反論してないじゃん。
お前が持ってきたそれ、戻り値はエラー値専用にしか使ってないだろ。
まぜるなって話をしているんだから、
正常な戻り値とエラー値を混ぜてる例を持って来いよ。
>>19
> 例えば"○○.txt"というファイルが存在することが前提、あるいは保証されるなら
> open系の関数呼び出し時にFileNotFound系のエラー処理は一切書かないよ。
書いたほうがいいと思うけど
なんで書かないの？
> 例えば"○○.txt"というファイルが存在することが前提、あるいは保証されるなら
> open系の関数呼び出し時にFileNotFound系のエラー処理は一切書かないよ。
書いたほうがいいと思うけど
なんで書かないの？
26 ：仕様書無しさん：2011/02/06(日) 17:50:51
27 ：仕様書無しさん：2011/02/06(日) 17:52:02
なんで単純な仕様も確認できないやつが例外を語れるのか不思議だよ
びちびち～
びちびち～
28 ：仕様書無しさん：2011/02/06(日) 17:54:45
それにファイルは絶対存在する前提とか まぬけなノミ脳もまだ健在だし
29 ：仕様書無しさん：2011/02/06(日) 17:56:20
HDDの故障率とか前提にいれれば、保障されない事は明白なのになあ
基本情報レベルの知識もないファイルが絶対ある前提君でした
基本情報レベルの知識もないファイルが絶対ある前提君でした
31 ：仕様書無しさん：2011/02/06(日) 17:59:45
おまえら、まともなロジックは担当させてもらえないほど馬鹿なんじゃねーの
PM「あ、前提君、君は catch(Exception e){ ぷりんとすたっくとれえす};
のコードを埋める仕事してください。よろしく!」
前提君「はっはいっっ、一生懸命catchコード書きます。うれしいな」
PM「戻り値文句君はエラーメッセージをSJISからUTF8にコンバートしてください
ロジックは担当しなくていいですよ、キャプテンの出来杉くんにはお茶だしてね」
PM「あ、前提君、君は catch(Exception e){ ぷりんとすたっくとれえす};
のコードを埋める仕事してください。よろしく!」
前提君「はっはいっっ、一生懸命catchコード書きます。うれしいな」
PM「戻り値文句君はエラーメッセージをSJISからUTF8にコンバートしてください
ロジックは担当しなくていいですよ、キャプテンの出来杉くんにはお茶だしてね」
>>31
よく考えたね。その恥ずかしい文章を。
よく考えたね。その恥ずかしい文章を。
あんまり細かいこと考えるとプログラム完成しなくなるぜｗ
例外のない言語でエラーを返す方法は3パターンあるかな。
１．戻り値にエラーを示す値を混ぜる。
２．戻り値は正常かエラーかを判断するためだけに使い、戻り値は関数の引数に返す
３．2とは逆に、正常化エラーかを判断するための変数を、関数の引数で戻す
さらに詳細なエラーを取得するための方法として、
１．戻り値の値から判断する。
２．関数を呼び出す。
３．グローバル変数errnoを参照する。
の方法がある。
グローバル変数はマルチスレッドで問題が出るから、
自分でerrnoのようなものを作るとき、気を付けろよ。
実はerrnoはただのグローバル変数ではない。
１．戻り値にエラーを示す値を混ぜる。
２．戻り値は正常かエラーかを判断するためだけに使い、戻り値は関数の引数に返す
３．2とは逆に、正常化エラーかを判断するための変数を、関数の引数で戻す
さらに詳細なエラーを取得するための方法として、
１．戻り値の値から判断する。
２．関数を呼び出す。
３．グローバル変数errnoを参照する。
の方法がある。
グローバル変数はマルチスレッドで問題が出るから、
自分でerrnoのようなものを作るとき、気を付けろよ。
実はerrnoはただのグローバル変数ではない。
36 ：仕様書無しさん：2011/02/06(日) 19:36:13
>>34って「おじゃば」かよ
どうも「おじゃば」臭いな
どうも「おじゃば」臭いな
エラーを戻り値で返す関数を
v = hoge(hage(hige()))
のような形で使う方法ってない？
v = hoge(hage(hige()))
のような形で使う方法ってない？
>>37
あるよ？
あるよ？
>>23
その前提だと全てのnewとmallocと変数宣言にもエラー処理書くのかという疑問がある。
あるいは全てのパイプ可能な標準出力やエラー出力において、書き込みエラーを検知するのかという疑問も。
どこで線引きをするのかは個々のプロジェクトに委ねられることだろう。
しかし何でもかんでもエラー処理すれば良いというものでもない。
その前提だと全てのnewとmallocと変数宣言にもエラー処理書くのかという疑問がある。
あるいは全てのパイプ可能な標準出力やエラー出力において、書き込みエラーを検知するのかという疑問も。
どこで線引きをするのかは個々のプロジェクトに委ねられることだろう。
しかし何でもかんでもエラー処理すれば良いというものでもない。
>>40
中身を変更することはできなくてもラップすることはできるでしょ
中身を変更することはできなくてもラップすることはできるでしょ
>>39
> その前提だと全てのnewとmallocと変数宣言にもエラー処理書くのかという疑問がある。
newは例外を吐くから書かなくてもいいと思う。
mallocはnullを返すから
その後変な動作をするかもしれないから危険だね。
エラー処理いれたほうがいいと思う。
> あるいは全てのパイプ可能な標準出力やエラー出力において、書き込みエラーを検知するのかという疑問も。
これもやったほうがいいんじゃない？
やらない理由はないはず。
> その前提だと全てのnewとmallocと変数宣言にもエラー処理書くのかという疑問がある。
newは例外を吐くから書かなくてもいいと思う。
mallocはnullを返すから
その後変な動作をするかもしれないから危険だね。
エラー処理いれたほうがいいと思う。
> あるいは全てのパイプ可能な標準出力やエラー出力において、書き込みエラーを検知するのかという疑問も。
これもやったほうがいいんじゃない？
やらない理由はないはず。
>>43
実行しなけりゃいいじゃん。
実行しなけりゃいいじゃん。
>>46
意味がわからん。
v = hoge(hage(hige()))
こういうシンプルなことをしたいだけ。
ただし、エラーが起きた場合は途中で中断し
親関数にどこでエラーが起きたかを返したいだけだよ。
意味がわからん。
v = hoge(hage(hige()))
こういうシンプルなことをしたいだけ。
ただし、エラーが起きた場合は途中で中断し
親関数にどこでエラーが起きたかを返したいだけだよ。
>>37
戻り値でのエラーを例外の throw に変換するラッパーを書いて、そっちを使えばいい。
戻り値でのエラーを例外の throw に変換するラッパーを書いて、そっちを使えばいい。
>>45
hoge, hage, hige全部ラップするんだよ。
v = hoge_rapper(hage_rapper(hige_rapper)));
このとき、higeでエラーがでたら-1, hageなら-2, hogeなら-3とか決めとく。
で、higeでエラーがでたらhigeラッパはエラーコード(-1)を返す。
hageラッパでエラー検知して何もせずエラーコードをhogeラッパに渡す。
それをうけたhogeラッパは何もせずにエラーコードを返す。
最後にvの中身をreturn
hoge, hage, hige全部ラップするんだよ。
v = hoge_rapper(hage_rapper(hige_rapper)));
このとき、higeでエラーがでたら-1, hageなら-2, hogeなら-3とか決めとく。
で、higeでエラーがでたらhigeラッパはエラーコード(-1)を返す。
hageラッパでエラー検知して何もせずエラーコードをhogeラッパに渡す。
それをうけたhogeラッパは何もせずにエラーコードを返す。
最後にvの中身をreturn
お前さ、どこがシンプルなんだよｗ
Ｃの実装に依存し、かつかなり高度なマクロが必要になる。
C89の標準だけじゃできんだろう。
どこのコンパイラ使ってるん？
そのマニュアルみるしかないよ。
Ｃの実装に依存し、かつかなり高度なマクロが必要になる。
C89の標準だけじゃできんだろう。
どこのコンパイラ使ってるん？
そのマニュアルみるしかないよ。
>>49 rap って・・・おまえ
>>49
俺スゲーとか思って書いたのそれ？
俺スゲーとか思って書いたのそれ？
54 ：仕様書無しさん：2011/02/06(日) 20:25:04
ぶっふぁはっはあ～
ゲラゲラ おじゃばは相変わらず笑わせてくれるぜ
ゲラゲラ おじゃばは相変わらず笑わせてくれるぜ
３行にすれば？だめなん？
>>56
でもエラー処理したいなら書くしかないでしょ。
でもエラー処理したいなら書くしかないでしょ。
バグ減らしたいんなら
v = hoge(hage(hige()))
こういうことやらないと思うけどねｗ
v = hoge(hage(hige()))
こういうことやらないと思うけどねｗ
60 ：仕様書無しさん：2011/02/06(日) 20:38:13
>>59 まともな人が良いことを言いました。
ここにいると、まともな感性がびちぐそのように崩れ去る
ここにいると、まともな感性がびちぐそのように崩れ去る
61 ：仕様書無しさん：2011/02/06(日) 20:39:41
＞v = hoge(hage(hige()))
↓
if(hige() == false) returu false;if(hage() == false) returu false;if(hoge() == false) returu false;
これが正解だろ。
あとはマクロで上に近い感じになるようにすればいい。
↓
if(hige() == false) returu false;if(hage() == false) returu false;if(hoge() == false) returu false;
これが正解だろ。
あとはマクロで上に近い感じになるようにすればいい。
スペル間違ったが気にしないでくれ。
この中で何人の人が、
例外なら、v = hoge(hage(hige())) の
まんまで理想的な動作になると
気づいているのだろうか？
例外なら、v = hoge(hage(hige())) の
まんまで理想的な動作になると
気づいているのだろうか？
ファイルが無かったら、さすがに何らかの異常処理を書くだろ。
66 ：仕様書無しさん：2011/02/06(日) 21:12:53
68 ：仕様書無しさん：2011/02/06(日) 21:13:54
ｼｰﾊｰ すき焼きうまかった・・
69 ：仕様書無しさん：2011/02/06(日) 21:16:54
例えば文字列を検索する関数があったとして、見つかったら位置、見つからなかったら-1を返す、
もし引数がおかしかったらArrayIndexOutOfBoundsやぬるぽなどの例外を出すとしよう。
検索文字列が見つからないのは異常かもしれないし、普通かもしれない。
そんな戻り値と例外のあわせ技なんてのもあるよね。
もし引数がおかしかったらArrayIndexOutOfBoundsやぬるぽなどの例外を出すとしよう。
検索文字列が見つからないのは異常かもしれないし、普通かもしれない。
そんな戻り値と例外のあわせ技なんてのもあるよね。
71 ：仕様書無しさん：2011/02/06(日) 21:19:33
>>70 得意のOracleに吸収されたJavaできましたね。
72 ：仕様書無しさん：2011/02/06(日) 21:21:39
なあんか、エラーってくくり、エラーの重篤度が平均して軽いんだよな
・致命的エラー 続行不能
・システムエラー 続行不能
・論理エラー 続行可能
・初期値エラー、デフォルト値代替で続行可能
のように重篤度をまず定義してもらわんと、スルーしていいのやら
切り分けがつかんのだけどねえ
・致命的エラー 続行不能
・システムエラー 続行不能
・論理エラー 続行可能
・初期値エラー、デフォルト値代替で続行可能
のように重篤度をまず定義してもらわんと、スルーしていいのやら
切り分けがつかんのだけどねえ
>>72
ぬるぽはどれに当てはまるん？
ぬるぽはどれに当てはまるん？
ロジカルなエラーだな
x * yを
x + yにして結果がエラーになる話。しかし金融のシステムだったら
大変なバグとなる。計測システムでもそうか。動作が落ちるとか言う話ではない
ただ 0div君やらかすと落ちるよ
x * yを
x + yにして結果がエラーになる話。しかし金融のシステムだったら
大変なバグとなる。計測システムでもそうか。動作が落ちるとか言う話ではない
ただ 0div君やらかすと落ちるよ
> ・初期値エラー、デフォルト値代替で続行可能
パスワードファイルがなければ、
デフォルトパスワードで続行可能でいいん？
パスワードファイルがなければ、
デフォルトパスワードで続行可能でいいん？
81 ：仕様書無しさん：2011/02/06(日) 21:32:49
人間が出来る面倒事を肩代わりするためのものだから
厳密には可能性のある内容については想定しておくのが正しい
あとはコストとの兼ね合い
設定不備をどこまでカバーしてやるかは見積もりで決めるだろ
存在する前提でチェックしない、みたいなことは
出来るだけ減らすほうがいいのは当たり前の話なんだけど、
仕様としてそういうのを想定しないでいい(動作補償しない)って決まってなければ
暗黙の了解でチェックしとくか、そういう機能を設けるか仕様確認する、のどっちかが普通な対応なんだけど
このあたり仕様として書いてないから、ファイルは存在する前提だから、つって
対応しなくていいって思ってる馬鹿は少なくない
厳密には可能性のある内容については想定しておくのが正しい
あとはコストとの兼ね合い
設定不備をどこまでカバーしてやるかは見積もりで決めるだろ
存在する前提でチェックしない、みたいなことは
出来るだけ減らすほうがいいのは当たり前の話なんだけど、
仕様としてそういうのを想定しないでいい(動作補償しない)って決まってなければ
暗黙の了解でチェックしとくか、そういう機能を設けるか仕様確認する、のどっちかが普通な対応なんだけど
このあたり仕様として書いてないから、ファイルは存在する前提だから、つって
対応しなくていいって思ってる馬鹿は少なくない
83 ：仕様書無しさん：2011/02/06(日) 21:34:49
そうか、データエラーというのもあるな ファイルの話はここに含まれるか
>>82
いきなりWindows95や*nixで動かされて
「動かねえぞ！どうなってんだ！」
「マニュアル読んでくださいよ。動作環境のところにwinxp以上、メモリ128MB以上って書いてあるでしょ！
今どき16MBのメモリしかないとかふざけないでくださいよ！」
なんてやりとりを想像した。
いきなりWindows95や*nixで動かされて
「動かねえぞ！どうなってんだ！」
「マニュアル読んでくださいよ。動作環境のところにwinxp以上、メモリ128MB以上って書いてあるでしょ！
今どき16MBのメモリしかないとかふざけないでくださいよ！」
なんてやりとりを想像した。
>>72
これで、わかったかい？
ようするに同じエラーでも
場合によって復帰可能な場合と
復帰できない場合がある。
それはエラーの内容ではなく、
どんな処理で起きたかで決まる。
だからエラーによって重篤度を定義するとか
できっこないのさ。
これで、わかったかい？
ようするに同じエラーでも
場合によって復帰可能な場合と
復帰できない場合がある。
それはエラーの内容ではなく、
どんな処理で起きたかで決まる。
だからエラーによって重篤度を定義するとか
できっこないのさ。
日本語でおｋ
>>86
無駄な機能に金かけてると他社に負けるよ。
無駄な機能に金かけてると他社に負けるよ。
>>88
これだけ分かりやすいのに理解出来ないのか？ｗ
これだけ分かりやすいのに理解出来ないのか？ｗ
>>67
なんで書き込み限定。
なんで書き込み限定。
93 ：仕様書無しさん：2011/02/06(日) 21:59:20
>>92
払えるコストは有限なんで、
「熱暴走したら？」「このPC、メモリにECCついてないけど大丈夫かな」「雷が落ちたら」「地震が来たら」
って感じで要求がエスカレートされても対応はできないよ。
コストの範囲内で優先順位つけて実装するだけ。
払えるコストは有限なんで、
「熱暴走したら？」「このPC、メモリにECCついてないけど大丈夫かな」「雷が落ちたら」「地震が来たら」
って感じで要求がエスカレートされても対応はできないよ。
コストの範囲内で優先順位つけて実装するだけ。
>>3
int _tmain(int argc, _TCHAR* argv[])
{
try
{
throw "ﾌﾟｷﾞｬｰ！";
}
catch (void*)
{
}
//catch (const char*)
//{
//}
}
VCで確認。キャッチしたよ。
環境に依存するから、いい書き方じゃないってことだね
int _tmain(int argc, _TCHAR* argv[])
{
try
{
throw "ﾌﾟｷﾞｬｰ！";
}
catch (void*)
{
}
//catch (const char*)
//{
//}
}
VCで確認。キャッチしたよ。
環境に依存するから、いい書き方じゃないってことだね
>>3,96 乙
>>95
うん。だから、うちでもエラーチェックは基本しないよ。
うん。だから、うちでもエラーチェックは基本しないよ。
おまえら、例外はCPUのエラーコードを言語がマッピングして例外オブジェクトを作っているのは
知っているよな？
まさか突然、例外オブジェクトが作られると思っていないよな？
どのタイミングで、どの例外クラスからインスタンスを作るのかを、どうやって決めているのか
もちろん知ってたよな、技術者なら常識だよなｗ
でっ戻り値がどうしたって？
知っているよな？
まさか突然、例外オブジェクトが作られると思っていないよな？
どのタイミングで、どの例外クラスからインスタンスを作るのかを、どうやって決めているのか
もちろん知ってたよな、技術者なら常識だよなｗ
でっ戻り値がどうしたって？
また…もういいや
void 2ch(Niko dou)
{
if (dou == null)
throw new ArgumentNullException("dou");
}
----
javaやc#での場合。
CPUの話と同関連してるのか教えてほしい
{
if (dou == null)
throw new ArgumentNullException("dou");
}
----
javaやc#での場合。
CPUの話と同関連してるのか教えてほしい
読み手にわかりやすいように明示的に記述するって概念がまったくない奴って
どういう環境でプログラム組んでるのか気になるな
こういう視点でみると例外は糞仕様なんだがな
そういう感性がない奴になにいっても無駄だと思うが
そもそも>>47みたいなコードをいいと思ってる時点でセンスが悪すぎる
hageだか、higeだかの関数がエラー返すんでしょ？
エラーが返ることを読み手にアピールしなきゃ駄目じゃない
こういう視点がまったく育たなかったＰＧってのは一体どういう教育うけたんだろうか？
どういう環境でプログラム組んでるのか気になるな
こういう視点でみると例外は糞仕様なんだがな
そういう感性がない奴になにいっても無駄だと思うが
そもそも>>47みたいなコードをいいと思ってる時点でセンスが悪すぎる
hageだか、higeだかの関数がエラー返すんでしょ？
エラーが返ることを読み手にアピールしなきゃ駄目じゃない
こういう視点がまったく育たなかったＰＧってのは一体どういう教育うけたんだろうか？
無視すんな！
コードを短くしたからいいってもんじゃないじゃん
そこに表現したいことを簡潔にわかりやすく記述してあることが美しいんじゃん
必要なことが書いてないor分かりにくいんじゃ本末転倒じゃん
そこに表現したいことを簡潔にわかりやすく記述してあることが美しいんじゃん
必要なことが書いてないor分かりにくいんじゃ本末転倒じゃん
>>103
> 読み手にわかりやすいように明示的に記述するって概念がまったくない奴って
> どういう環境でプログラム組んでるのか気になるな
読み手ってｗ
ソースコードを素人に見せたってわかる訳ないだろ？
結局は、読み手がどれぐらいの知識を持っているかで
分かりやすいかどうかは変わるんだよ。
例外を知らない人には、例外を使ったソースが分からない。
それだけの話だ。ちゃんと知識がある人にとってはわかる。
そんなに明示的に記述したければ、mallocが
どうやってOSからメモリを割り当ててもらって、
それをどうやって使用しているか、明示的に書いてからいえ。
> 読み手にわかりやすいように明示的に記述するって概念がまったくない奴って
> どういう環境でプログラム組んでるのか気になるな
読み手ってｗ
ソースコードを素人に見せたってわかる訳ないだろ？
結局は、読み手がどれぐらいの知識を持っているかで
分かりやすいかどうかは変わるんだよ。
例外を知らない人には、例外を使ったソースが分からない。
それだけの話だ。ちゃんと知識がある人にとってはわかる。
そんなに明示的に記述したければ、mallocが
どうやってOSからメモリを割り当ててもらって、
それをどうやって使用しているか、明示的に書いてからいえ。
>>106
>例外を知らない人には、例外を使ったソースが分からない。
>それだけの話だ。ちゃんと知識がある人にとってはわかる。
わかんないって
少なくともこれ↓が例外返すかどうかは関数の中身みなきゃわからないじゃん
> v = hoge(hage(hige()))
これは明示的にって視点でみたときに非常に駄目なコードじゃないか？
ちなみに一応聞いておくけど関数名にf0001とかつけるのは駄目ってぐらいの常識はあるよね？
>例外を知らない人には、例外を使ったソースが分からない。
>それだけの話だ。ちゃんと知識がある人にとってはわかる。
わかんないって
少なくともこれ↓が例外返すかどうかは関数の中身みなきゃわからないじゃん
> v = hoge(hage(hige()))
これは明示的にって視点でみたときに非常に駄目なコードじゃないか？
ちなみに一応聞いておくけど関数名にf0001とかつけるのは駄目ってぐらいの常識はあるよね？
そもそも例外を発生させる事が問題なんだから
例外なしで作ればイイ
例外なしで作ればイイ
>>107
> 少なくともこれ↓が例外返すかどうかは関数の中身みなきゃわからないじゃん
だから、全く理解できてないと言うんだ。
お前には発想の転換が必要なんだ。
太陽が地球の周りを回っていると思い込んでいる人に
地球のほうが太陽の周りを回っているんじゃないのか？って
いうような気分だな。
例外を返すかどうかと考える必要がない。
すべての関数（式も）は例外を返すと考えるんだよ。
すべての関数が例外を返すのだから、
中を見る必要はないじゃないか。
> 少なくともこれ↓が例外返すかどうかは関数の中身みなきゃわからないじゃん
だから、全く理解できてないと言うんだ。
お前には発想の転換が必要なんだ。
太陽が地球の周りを回っていると思い込んでいる人に
地球のほうが太陽の周りを回っているんじゃないのか？って
いうような気分だな。
例外を返すかどうかと考える必要がない。
すべての関数（式も）は例外を返すと考えるんだよ。
すべての関数が例外を返すのだから、
中を見る必要はないじゃないか。
>>107
関数の中身を見たところで、その関数が将来的にどうなるのかまでは分からないだろ。
ひょっとすると、明日には関数内部のバグが修正されて、例外が出なくなるかもしれんし、出るようになるかもしれん。
どっちでも、例外ならとりあえず問題が起こった後分析が可能。
関数の中身を見たところで、その関数が将来的にどうなるのかまでは分からないだろ。
ひょっとすると、明日には関数内部のバグが修正されて、例外が出なくなるかもしれんし、出るようになるかもしれん。
どっちでも、例外ならとりあえず問題が起こった後分析が可能。
>>109
階層上の関数がcatchして対処しなきゃなんねー例外が１つもないときしか意味なくねそれ
そーゆー使い方でいいのか？
誰も責任持たないからメインにいたるまで誰も処理しないけど
それはそれでいいの？
階層上の関数がcatchして対処しなきゃなんねー例外が１つもないときしか意味なくねそれ
そーゆー使い方でいいのか？
誰も責任持たないからメインにいたるまで誰も処理しないけど
それはそれでいいの？
>>111
なぜ誰も責任を持たないと思うのか？
自分がその例外を対処できると思うのなら
思った箇所で対処すればいい。
対処したいと思えば、どの時点でも
catchして対処できる。
そのための命令は備えている。
なぜ誰も責任を持たないと思うのか？
自分がその例外を対処できると思うのなら
思った箇所で対処すればいい。
対処したいと思えば、どの時点でも
catchして対処できる。
そのための命令は備えている。
>>112
なんの例外が返ってくるのか関数の中身みなきゃわかんねーじゃん
なんの例外が返ってくるのか関数の中身みなきゃわかんねーじゃん
つか>>107の表現はおかしくねぇ？
仕様上関数が例外を投げないのか
例外をわざとスルーしてるのか
バグでcatchが抜けてるのか
判断しづらいてことじゃねーの？
メソッドのヘッダコメント辺りに発生し得る例外の
一覧でもあれば良いと思うけどな。
>>110
バグはバグ、仕様は仕様で仕様が変わったら
影響を検討すんのは当たり前だろ。
仕様上関数が例外を投げないのか
例外をわざとスルーしてるのか
バグでcatchが抜けてるのか
判断しづらいてことじゃねーの？
メソッドのヘッダコメント辺りに発生し得る例外の
一覧でもあれば良いと思うけどな。
>>110
バグはバグ、仕様は仕様で仕様が変わったら
影響を検討すんのは当たり前だろ。
>>116
ほとんどの例外で、対処する内容は同じだ。
対処方法は一つしかないのだから、
どう対処するということを考える必要がない。
○○の例外のときは違う処理をしたいと
思うのなら○○の例外の時だけ違う処理を書けばいい。
○○ときと自分で分かっているのだから、それは対処できることだ。
ほとんどの例外で、対処する内容は同じだ。
対処方法は一つしかないのだから、
どう対処するということを考える必要がない。
○○の例外のときは違う処理をしたいと
思うのなら○○の例外の時だけ違う処理を書けばいい。
○○ときと自分で分かっているのだから、それは対処できることだ。
>>116
キャッチしたいものだけキャッチして、それ以外は放置すればいいのよ
キャッチしたいものだけキャッチして、それ以外は放置すればいいのよ
>>119
だから、すべての例外で
同じ処理をするのだから、
どんな例外がでようが関係ないし、
対処方法で悩むこともない。
自分で違う処理をしたいと思った時だけ
やればいいが、自分で違う処理をしたいと
わかっているのだから、それは可能なことだ。
だから、すべての例外で
同じ処理をするのだから、
どんな例外がでようが関係ないし、
対処方法で悩むこともない。
自分で違う処理をしたいと思った時だけ
やればいいが、自分で違う処理をしたいと
わかっているのだから、それは可能なことだ。
よし、かなりおつむ弱いな
話を元にもどそうか？
>例外を知らない人には、例外を使ったソースが分からない。
>それだけの話だ。ちゃんと知識がある人にとってはわかる。
わかんないって
少なくともこれ↓が例外返すかどうかは関数の中身みなきゃわからないじゃん
> v = hoge(hage(hige()))
これは明示的にって視点でみたときに非常に駄目なコードじゃないか？
という話だったよね？
話を元にもどそうか？
>例外を知らない人には、例外を使ったソースが分からない。
>それだけの話だ。ちゃんと知識がある人にとってはわかる。
わかんないって
少なくともこれ↓が例外返すかどうかは関数の中身みなきゃわからないじゃん
> v = hoge(hage(hige()))
これは明示的にって視点でみたときに非常に駄目なコードじゃないか？
という話だったよね？
>>121
話戻してもループするだけだぞ。
> 少なくともこれ↓が例外返すかどうかは関数の中身みなきゃわからないじゃん
だから、全く理解できてないと言うんだ。
お前には発想の転換が必要なんだ。
太陽が地球の周りを回っていると思い込んでいる人に
地球のほうが太陽の周りを回っているんじゃないのか？って
いうような気分だな。
例外を返すかどうかと考える必要がない。
すべての関数（式も）は例外を返すと考えるんだよ。
すべての関数が例外を返すのだから、
中を見る必要はないじゃないか。
話戻してもループするだけだぞ。
> 少なくともこれ↓が例外返すかどうかは関数の中身みなきゃわからないじゃん
だから、全く理解できてないと言うんだ。
お前には発想の転換が必要なんだ。
太陽が地球の周りを回っていると思い込んでいる人に
地球のほうが太陽の周りを回っているんじゃないのか？って
いうような気分だな。
例外を返すかどうかと考える必要がない。
すべての関数（式も）は例外を返すと考えるんだよ。
すべての関数が例外を返すのだから、
中を見る必要はないじゃないか。
>> v = hoge(hage(hige()))
>これは明示的にって視点でみたときに非常に駄目なコードじゃないか？
たぶん、このレベルの話には誰も反論してないと思う。
俺だって、こんな書き方されたらなんか言うと思うもの
>これは明示的にって視点でみたときに非常に駄目なコードじゃないか？
たぶん、このレベルの話には誰も反論してないと思う。
俺だって、こんな書き方されたらなんか言うと思うもの
>>123
だよねぇ
だよねぇ
>>123-124
満足したか？
じゃあ、話を戻そうか。
>>119
だから、すべての例外で
同じ処理をするのだから、
どんな例外がでようが関係ないし、
対処方法で悩むこともない。
自分で違う処理をしたいと思った時だけ
やればいいが、自分で違う処理をしたいと
わかっているのだから、それは可能なことだ。
満足したか？
じゃあ、話を戻そうか。
>>119
だから、すべての例外で
同じ処理をするのだから、
どんな例外がでようが関係ないし、
対処方法で悩むこともない。
自分で違う処理をしたいと思った時だけ
やればいいが、自分で違う処理をしたいと
わかっているのだから、それは可能なことだ。
明示的、明示的とはいうけれどシステムハンガリアンは嫌だよ。
予期しない例外が飛んでくる可能性があるなら
catcy(Exception)でキャッチして後始末（リソース解放等）できるようにするか、
RAIIのような例外安全な設計を心がけるかするといい。
catcy(Exception)でキャッチして後始末（リソース解放等）できるようにするか、
RAIIのような例外安全な設計を心がけるかするといい。
この手の万能バカの相手すんのそろそろやめろよ…
結局分からんな…
プログラム全体を１人で作っているならいいんだけど
多人数で作っている場合の例外の処理方法がまったく分からない…
スローする人は誰にも相談せずソローしてOKなん？
これがOKとするならば、受ける人は完全に何が来るのか、
もしくはこないのかも分からない。例外の種類も分からん。
だから全例外をキャッチするコードを書いて、潰す処理をするのは
正しいように思える。
プログラム全体を１人で作っているならいいんだけど
多人数で作っている場合の例外の処理方法がまったく分からない…
スローする人は誰にも相談せずソローしてOKなん？
これがOKとするならば、受ける人は完全に何が来るのか、
もしくはこないのかも分からない。例外の種類も分からん。
だから全例外をキャッチするコードを書いて、潰す処理をするのは
正しいように思える。
例外だろうが戻り値だろうが参照渡しのパラメータだろうが
プロトコル決めもせんで多人数どころかふたりで作っても
まともにできるわきゃねーだろが。
どーしてそーどいつもこいつも極端に走るんだ？仕事したことねーのか？
プロトコル決めもせんで多人数どころかふたりで作っても
まともにできるわきゃねーだろが。
どーしてそーどいつもこいつも極端に走るんだ？仕事したことねーのか？
>例外だろうが戻り値だろうが参照渡しのパラメータだろうが
言っていることがおかしいぜ？
戻り値や参照渡しのパラメータは取り決めをする。当たり前。
だが例外は違うんだろ？
例外は自由にスローしていいし、上位側を気にする必要がないと、例外擁護派は主張する。
だが、そんなことが他人数で開発する現場では上手くいくとは思えない。
ここに関しては理解を得られる回答がきた試しがない。
言っていることがおかしいぜ？
戻り値や参照渡しのパラメータは取り決めをする。当たり前。
だが例外は違うんだろ？
例外は自由にスローしていいし、上位側を気にする必要がないと、例外擁護派は主張する。
だが、そんなことが他人数で開発する現場では上手くいくとは思えない。
ここに関しては理解を得られる回答がきた試しがない。
そんな奴は若干一名？くらいでがんばってる例外バカしかいねーじゃん。
こんなのを相手するほうがアホだっつーの。
こんなのを相手するほうがアホだっつーの。
133 ：仕様書無しさん：2011/02/07(月) 07:20:08
みんな、ぼくのかんがえたさいきょうのれいがいにあわせてねｗｗｗ
例外は上位側を気にせずスローって主張はある意味正しいかもしれん。
何しろ自分が作った関数で直接スローしなくても
自分の下位からスローされるかも知れないからね。
それを嫌がって、自分の関数をtryで全部囲って
かわりにMyExceptionをスローする人が後を絶たないんだろうけど。
自関数を通過する例外など精神衛生上よくないだろうからな。
自関数内の後処理行を実行できなかったりもするし。
何しろ自分が作った関数で直接スローしなくても
自分の下位からスローされるかも知れないからね。
それを嫌がって、自分の関数をtryで全部囲って
かわりにMyExceptionをスローする人が後を絶たないんだろうけど。
自関数を通過する例外など精神衛生上よくないだろうからな。
自関数内の後処理行を実行できなかったりもするし。
>かわりにMyExceptionをスローする人が後を絶たないんだろうけど。
あの、ふつー例外も設計するから。
いきなり「ぼくのかんがえた」例外投げるわけねぇだろ。
あの、ふつー例外も設計するから。
いきなり「ぼくのかんがえた」例外投げるわけねぇだろ。
136 ：仕様書無しさん：2011/02/07(月) 07:57:10
処理関数内でファイルオープンに失敗して例外スローされたり、ヒープ
メモリの確保に失敗したのを、いちいち上位に投げられたらたまらんな。
コンストラクタ内でnewに失敗してもそのままとか。(w
そもそも、全て上位に投げるなら、どこかでエラーが起きたら即座に
終了してしまう糞プログラムか、全ての例外処理がmain()内に書か
れた糞プログラムのどちらかになるだろう。
メモリの確保に失敗したのを、いちいち上位に投げられたらたまらんな。
コンストラクタ内でnewに失敗してもそのままとか。(w
そもそも、全て上位に投げるなら、どこかでエラーが起きたら即座に
終了してしまう糞プログラムか、全ての例外処理がmain()内に書か
れた糞プログラムのどちらかになるだろう。
自分より下位で発生したバグを見つけるためには握りつぶしはご法度。
知らない例外はスルーか上に再送しろ。
仕様に規定されていないMyExceptionは勝手に作るな、投げるな。
最低限のテストケースは例外が出なくなるまでデバッグしろ。
運用時に想定外の例外が出てストップしたなら即座に使用を中止して改修しろ。
騙し騙し使おうとかバカなこと考えてんじゃねーよ。
知らない例外はスルーか上に再送しろ。
仕様に規定されていないMyExceptionは勝手に作るな、投げるな。
最低限のテストケースは例外が出なくなるまでデバッグしろ。
運用時に想定外の例外が出てストップしたなら即座に使用を中止して改修しろ。
騙し騙し使おうとかバカなこと考えてんじゃねーよ。
ソレを踏まえてちゃんとした例外の設計はこんなのがオススメ、とか
建設的な話にすればいいじゃん。
でもそれだと盛り上がらないんだよなーｗ
建設的な話にすればいいじゃん。
でもそれだと盛り上がらないんだよなーｗ
139 ：仕様書無しさん：2011/02/07(月) 08:16:12
>>137
お前アプリ屋かCGI屋かどっちかだろ。
お前アプリ屋かCGI屋かどっちかだろ。
>>138
だって戻り値派は明らかに例外追放派じゃん
だって戻り値派は明らかに例外追放派じゃん
例外を正しく理解してないからでしょ
そーゆーナニ派とかくだらん煽りを入れるお前はナニ屋よｗ
ちゃんと仕事をしたことがなさそうだが。
ちゃんと仕事をしたことがなさそうだが。
144 ：仕様書無しさん：2011/02/07(月) 09:38:14
私が代わりに答えましょう。
まず、コンパイルエラーがなくならない程度なので
実行確認まで至らないアホです。
まず、コンパイルエラーがなくならない程度なので
実行確認まで至らないアホです。
145 ：仕様書無しさん：2011/02/07(月) 09:45:13
>よし、かなりおつむ弱いな
>よし、かなりおつむ弱いな
>よし、かなりおつむ弱いな
>よし、かなりおつむ弱いな
>よし、かなりおつむ弱いな
>よし、かなりおつむ弱いな
>よし、かなりおつむ弱いな
>よし、かなりおつむ弱いな
>よし、かなりおつむ弱いな
例外使うと、かっこ良く見えるの？
>>47みたいなコードが生成できてしまうってことで十分例外を否定する理由になる
そりゃ戻り値でだってlongjmpすりゃできんだから、例外のせいじゃなくて
>47がバカなだけ。ったく、つまらんことで煽るなよタコ。
>47がバカなだけ。ったく、つまらんことで煽るなよタコ。
例外を返す返さないは関数の中身みなきゃわからないって時点でもうねｗ
「好き勝手にスローしていいの？」って、そういうことは設計段階で考慮しろよ
メモリ確保失敗とかファイルオープン失敗を無視するのは、単にバグなんじゃねーの
その機能がそもそも復旧の担当じゃないなら、呼び出した側が考慮しろ
なんつーか、このスレで例外にファビョってんのは馬鹿ばっかなのか？
だいたいクラス、メソッドの機能で投げる可能性のある例外なんて絞られるだろ
呼び出すものがまだ出来てないなら、I/Fだけ事前に担当と明確に打ち合わせて
自分とこではダミークラスつくっときゃ実装もテストも支障ねーっすよ
自分の担当で捕まえる例外は、呼び出す処理の出す例外のうち、
自分が復旧して自分のやる処理の残りが行える例外の捕捉と復旧
例えば、parseやキャストでこけた場合に、初期値を使う、みたいな仕様とかで
var param; try{ param = parse();} catch(parseできなかったよException ex){ param = DEFAULT_PARAM;}
みたいな感じで復旧するとかそんな感じ
もちろん、正常系の一部に例外スローが入るのがいやだからって、
parseする前に事前に値をチェックする人もいるし、この辺りは好み
ファイルが開けなかった場合とかで、そこで処理を中断する場合、
中断するってのが仕様上自分の担当部分の責務になってんなら、
自分とこでキャッチして失敗時の処理までやる
なってなければ例外をなげて自分の処理は終わる
処理として復旧はできても、仕様として自分が復旧できない場合は、
基本的に全部無視するべき(自分の後続処理ができないなら捕まえない)
ただし、捕まえて（場合によってはログ吐いて）、
別のプロジェクトの共通例外に格納したり投げなおしたりするってことも
コーディングルールとして共通処理的にやるようにきまってる場合もある
業務エラーとかはこうなってることが多い
メモリ確保失敗とかファイルオープン失敗を無視するのは、単にバグなんじゃねーの
その機能がそもそも復旧の担当じゃないなら、呼び出した側が考慮しろ
なんつーか、このスレで例外にファビョってんのは馬鹿ばっかなのか？
だいたいクラス、メソッドの機能で投げる可能性のある例外なんて絞られるだろ
呼び出すものがまだ出来てないなら、I/Fだけ事前に担当と明確に打ち合わせて
自分とこではダミークラスつくっときゃ実装もテストも支障ねーっすよ
自分の担当で捕まえる例外は、呼び出す処理の出す例外のうち、
自分が復旧して自分のやる処理の残りが行える例外の捕捉と復旧
例えば、parseやキャストでこけた場合に、初期値を使う、みたいな仕様とかで
var param; try{ param = parse();} catch(parseできなかったよException ex){ param = DEFAULT_PARAM;}
みたいな感じで復旧するとかそんな感じ
もちろん、正常系の一部に例外スローが入るのがいやだからって、
parseする前に事前に値をチェックする人もいるし、この辺りは好み
ファイルが開けなかった場合とかで、そこで処理を中断する場合、
中断するってのが仕様上自分の担当部分の責務になってんなら、
自分とこでキャッチして失敗時の処理までやる
なってなければ例外をなげて自分の処理は終わる
処理として復旧はできても、仕様として自分が復旧できない場合は、
基本的に全部無視するべき(自分の後続処理ができないなら捕まえない)
ただし、捕まえて（場合によってはログ吐いて）、
別のプロジェクトの共通例外に格納したり投げなおしたりするってことも
コーディングルールとして共通処理的にやるようにきまってる場合もある
業務エラーとかはこうなってることが多い
>わりと簡単に止まっていいもんと
>出来るだけ止まっちゃならんもんで
この時点でずいぶん貴賤入ってるようなｗ
>出来るだけ止まっちゃならんもんで
この時点でずいぶん貴賤入ってるようなｗ
そんな長い文章書いてもちっとも例外のメリットが見えないなｗ
>例外にファビョってんのは馬鹿ばっか
そうだよ。戻り値派とやらにファビョってんのも同じ（くらい）馬鹿だし。
そうだよ。戻り値派とやらにファビョってんのも同じ（くらい）馬鹿だし。
>>149
この人たちになに言っても無駄ですよ。
1.まず設計の知識はゼロ
2.テストケースの知識もゼロ
3.要件ありきでプログラムを思考できない(だからなに言っても無駄なんですけどね)
俺はカーネル屋
この人たちになに言っても無駄ですよ。
1.まず設計の知識はゼロ
2.テストケースの知識もゼロ
3.要件ありきでプログラムを思考できない(だからなに言っても無駄なんですけどね)
俺はカーネル屋
そんなしっかりした奴がこんなとこでくだらん煽りするかよｗ
>>149
以下のレスがこの人たちを物語っていますよねw
>>152 なんで要件によって「まあ止まっても支障ないか」「止まったら厳罰」
の切り分けが貴賎になるのか? 頭がかなりノーベル賞系になっていますよね。
以下のレスがこの人たちを物語っていますよねw
>>152 なんで要件によって「まあ止まっても支障ないか」「止まったら厳罰」
の切り分けが貴賎になるのか? 頭がかなりノーベル賞系になっていますよね。
例外の動作は仕様書になんて書くんだろ？
いやあ、この人たち見ていると「もう日本はだめだ」と思っちゃって
つい・・・ なんとかがんばって欲しいです。
最小不幸社会の申し子なのかしら
つい・・・ なんとかがんばって欲しいです。
最小不幸社会の申し子なのかしら
>>158のレスは
>1.まず設計の知識はゼロ ←当たってますねえ
>1.まず設計の知識はゼロ ←当たってますねえ
だよなぁ。
> v = hoge(hage(hige()))
こう書けるのが効率的だとかコストが低いとか言うバカ相手にしてもしかたねーよ。
> v = hoge(hage(hige()))
こう書けるのが効率的だとかコストが低いとか言うバカ相手にしてもしかたねーよ。
>>158
何も書いてなければ java.lang.Exception なり std::exception なりが飛んでくるものとする。
そうでない関数は
・例外を投げない、あるいは
・特定の例外のみ投げる
ものと明記する。
これでわりといける気がする。なんかマズイところあるかな？
何も書いてなければ java.lang.Exception なり std::exception なりが飛んでくるものとする。
そうでない関数は
・例外を投げない、あるいは
・特定の例外のみ投げる
ものと明記する。
これでわりといける気がする。なんかマズイところあるかな？
少なくとも「リリース版でさえどんな例外やバグが潜んでるかわからない」クオリティで
「止まってはいけないプログラム」なんて書けるわけないってことはわかる。
「止まってはいけないプログラム」なんて書けるわけないってことはわかる。
>>161
社内の研修のときとか、モチベーションが下がったときにパズルではやるんですよねえ
前提は「これは遊びでけっして業務にこの考えを使わない」としっかり言ってから
開始 @を一文字づつ出力して色々な図形を書くんですけど
できるだけ短く書け
優秀な人の平均20行程度ですけど
ぶっとんだ人はマクロ展開しつつ1行で書きました。俺はアホだから書けません。
社内の研修のときとか、モチベーションが下がったときにパズルではやるんですよねえ
前提は「これは遊びでけっして業務にこの考えを使わない」としっかり言ってから
開始 @を一文字づつ出力して色々な図形を書くんですけど
できるだけ短く書け
優秀な人の平均20行程度ですけど
ぶっとんだ人はマクロ展開しつつ1行で書きました。俺はアホだから書けません。
ことJavaに関して言えば投げた例外は呼出し元でcatchしないと
コンパイルエラーになるから、チェック漏れという点では役に立つような。
コンパイルエラーになるから、チェック漏れという点では役に立つような。
開発タイプの前提
1.通信、カーネル屋 動いて当たり前、エラーチェックは厳密にこれでもかってする
2.Web屋 どうせスクリプトで書くし、500番とかわけのわからないエラーがでるから
まあそこそこエラーチェック
3.Java屋 もっさりどろどろした環境でひとつのバグ追跡も時間がかかり、分けのわからん
例外割り込みが入っていつまでたっても動作しないから、例外を握りつぶして
うそでも(バグてんこ盛り状態でも)かたちだけ動作させようとする
1.通信、カーネル屋 動いて当たり前、エラーチェックは厳密にこれでもかってする
2.Web屋 どうせスクリプトで書くし、500番とかわけのわからないエラーがでるから
まあそこそこエラーチェック
3.Java屋 もっさりどろどろした環境でひとつのバグ追跡も時間がかかり、分けのわからん
例外割り込みが入っていつまでたっても動作しないから、例外を握りつぶして
うそでも(バグてんこ盛り状態でも)かたちだけ動作させようとする
社会に出てませんと宣言してるわけだなｗ
>>161
そーゆーの育っちゃう環境ってどーゆー人が教えてるんだろうね
そーゆーの育っちゃう環境ってどーゆー人が教えてるんだろうね
不具合があった場合に改修する必要があるのは当たり前
ただ、止まらせるとまずいものは、止まらないように最終的なもみ消し処理も考慮しておく必要はあるよ
例えば駅の自動改札の非接触ICカードの処理とか
止まったけど
ただ、止まらせるとまずいものは、止まらないように最終的なもみ消し処理も考慮しておく必要はあるよ
例えば駅の自動改札の非接触ICカードの処理とか
止まったけど
>>167
Javaが嫌いなのはわかるけど、このスレでやることじゃないよね？
Javaが嫌いなのはわかるけど、このスレでやることじゃないよね？
例外握りつぶして形だけでも動作させるのは、
Web寄りやパソコンで使うアプリケーションではあまりやらないだろ
Web系は(基本的には)1リクエスト1レスポンスで終わるから、
想定外かつレアケースで止まっても大きな問題にならないことすらある
PCアプリなら、丁寧なやつはバグレポ送信とか用意したりしてることはあるけど、
それで普通に終了しておしまい。不安定な状況で動かすとか、他に影響与えるような事怖くて出来るわけない
結局は再リクエスト、再起動してもらえばいいだけだから運用による復旧が容易
んなこたJavaだろうが他の言語だろうが関係ない。常識でしょ
組込み系だと逆に止まることが問題だから最後は握り潰すけどな
Web寄りやパソコンで使うアプリケーションではあまりやらないだろ
Web系は(基本的には)1リクエスト1レスポンスで終わるから、
想定外かつレアケースで止まっても大きな問題にならないことすらある
PCアプリなら、丁寧なやつはバグレポ送信とか用意したりしてることはあるけど、
それで普通に終了しておしまい。不安定な状況で動かすとか、他に影響与えるような事怖くて出来るわけない
結局は再リクエスト、再起動してもらえばいいだけだから運用による復旧が容易
んなこたJavaだろうが他の言語だろうが関係ない。常識でしょ
組込み系だと逆に止まることが問題だから最後は握り潰すけどな
>>173 組み込みでもウォッチドッグタイマーとかで不正な状態は回復させるようになってるんじゃない？
Javaのロクでもないコードで見かけるのは、例外をcatchしてませんと
Eclipseが文句を言うのでとりあえずcatch入れた、ようなの。
なんとなく動いてるｗだけなんだよね。
こんなのメンテさせられる側はたまらん。
でも根本的にリファクタリングして得なこともないから
郷にいれば郷に従っちゃったり。
しょせんイヤイヤ生活のためにやってるんだしそんなもんだよ。
Eclipseが文句を言うのでとりあえずcatch入れた、ようなの。
なんとなく動いてるｗだけなんだよね。
こんなのメンテさせられる側はたまらん。
でも根本的にリファクタリングして得なこともないから
郷にいれば郷に従っちゃったり。
しょせんイヤイヤ生活のためにやってるんだしそんなもんだよ。
Javaはいまでこそ溢れ返ってゴミばっかだけど
当時金のなる木だったんだから、職業マが腐るほど量産された
その遺物(汚物)がいまいろいろなとこで迷惑掛けてる
そういう意味では糞コードの多い言語ではある
(VBがいやな顔されるのも似たようなもんだし)
例外が正しく使えないのも、概ねはそういう奴らもしくはただの老害のことが殆どなんだけど
そこをわざわざ言語叩きに摩り替えたがる見識の狭い奴は何が目的なんだよｗ
当時金のなる木だったんだから、職業マが腐るほど量産された
その遺物(汚物)がいまいろいろなとこで迷惑掛けてる
そういう意味では糞コードの多い言語ではある
(VBがいやな顔されるのも似たようなもんだし)
例外が正しく使えないのも、概ねはそういう奴らもしくはただの老害のことが殆どなんだけど
そこをわざわざ言語叩きに摩り替えたがる見識の狭い奴は何が目的なんだよｗ
>>174
普通のアプリだって「落ちたら再起動」くらいできるよ。やらないだけで。
普通のアプリだって「落ちたら再起動」くらいできるよ。やらないだけで。
カーネル屋ｗ
そうやってコロコロ開発スタイル変え続けるのが、本当にいいことなのか疑問だけどね。
どうせ数年後には、ぜんぜん違うネタで似たような事ホザいてるだろうし。
どうせ数年後には、ぜんぜん違うネタで似たような事ホザいてるだろうし。
柔軟に対応できなくなった堅物老害は世の中から必要とされなくなるんですよ
そーそー。
> v = hoge(hage(hige()))
こういう効率的でコストの低いコードを書く若者が必要とされてるんですよｗ
> v = hoge(hage(hige()))
こういう効率的でコストの低いコードを書く若者が必要とされてるんですよｗ
こまけー揚げ足ばっかとってるな
183 ：仕様書無しさん：2011/02/07(月) 21:19:13
すてきなコードですねえ、ほんと
> v = hoge(hage(hige(piyo(unko(kasu(div0())))))) セミコロン必要ですよお
> v = hoge(hage(hige(piyo(unko(kasu(div0())))))) セミコロン必要ですよお
184 ：仕様書無しさん：2011/02/07(月) 21:21:12
最初から最後まで動作しないプログラムコンテストがあったら
v = hoge(hage(hige()))君は優勝しますよ、絶対!
v = hoge(hage(hige()))君は優勝しますよ、絶対!
int a;
char b;
long c;
a = hige();
b = hage(a);
c = hoge(b);
こう書くよりはすっきりしてて良いんだけどね。
char b;
long c;
a = hige();
b = hage(a);
c = hoge(b);
こう書くよりはすっきりしてて良いんだけどね。
それでいいんじゃないの、仕事にしなきゃ。
よほど年齢のこと言われたのが辛かったのか
Lispをやるとまた話がｗ
例外の話じゃないような？
> v = hoge(hage(hige()))
こういうコード書いてた時期もあったが、
デバッグしにくいよねーってことでわりと素直に書き下すようになったな。
こういうコード書いてた時期もあったが、
デバッグしにくいよねーってことでわりと素直に書き下すようになったな。
例外があれば
> v = hoge(hage(hige()))
こういう効率的でコストの低いコードが使えるのが利点だそうだし、いいんじゃね？
> v = hoge(hage(hige()))
こういう効率的でコストの低いコードが使えるのが利点だそうだし、いいんじゃね？
例外使いたいときに、Tester-Doer パターンが使えないとなんかムカつく。
ファイルがあるかどうか確認するためにIsExistsみたいなメソッドを作ろうとして（っていうか、なんで作らなきゃいかんのよ、ふつう最初からあるだろ）
bool IsExists(string fileUrl)
{
try
{
GetFile(fileUrl);
return true;
}
catch (FileNotFoundException)
{
return false;
}
}
みたいなこと書かなきゃならんのが、超ムカつく。
出来れば例外は出したくないのよ……出たときは全部バグ扱いしたいのさ
ファイルがあるかどうか確認するためにIsExistsみたいなメソッドを作ろうとして（っていうか、なんで作らなきゃいかんのよ、ふつう最初からあるだろ）
bool IsExists(string fileUrl)
{
try
{
GetFile(fileUrl);
return true;
}
catch (FileNotFoundException)
{
return false;
}
}
みたいなこと書かなきゃならんのが、超ムカつく。
出来れば例外は出したくないのよ……出たときは全部バグ扱いしたいのさ
>>192
> ファイルがあるかどうか確認するためにIsExistsみたいなメソッドを作ろうとして
> （っていうか、なんで作らなきゃいかんのよ、ふつう最初からあるだろ）
お前がIsExistsとか言ってるからだろ。
普通はExistsだ。
アホめ。
> ファイルがあるかどうか確認するためにIsExistsみたいなメソッドを作ろうとして
> （っていうか、なんで作らなきゃいかんのよ、ふつう最初からあるだろ）
お前がIsExistsとか言ってるからだろ。
普通はExistsだ。
アホめ。
> v = hoge(hage(hige()))
最近は、メソッドチェーンと言って、
hoge().hage().hige() という
書き方が流行ってるよ。
ま、昔のおっさんは今を知らないだろうけど。
最近は、メソッドチェーンと言って、
hoge().hage().hige() という
書き方が流行ってるよ。
ま、昔のおっさんは今を知らないだろうけど。
>>913
どっちもありませんが何か？
どっちもありませんが何か？
関数型言語A
(piyo (hage hoge))
関数型言語B
hoge |> hage |> piyo
関数型言語C
hage . hoge $ piyo
スタック型言語D
piyo hoge hage
(piyo (hage hoge))
関数型言語B
hoge |> hage |> piyo
関数型言語C
hage . hoge $ piyo
スタック型言語D
piyo hoge hage
C以降間違ってるがネタですので
>>193
Booleanを戻りに持つメソッドはisで始めないといけないと勘違いしてるんでそ
結構勘違いしてる人いるよ。Bool格納する変数にisつけたりもよく見る
>>192
そもそもこの手の存在チェックって、チェック時点でOKになっても
実際に参照するときにOKである補償がないから、こういうメソッドって作る意味ないよ()笑
ましてやTesterのなかに例外処理入れてたら本末転倒。お勉強しなおしてくださいな
事前にテストするっつーのは、例えば
入力された文字列が日付に変換できる場合にはそれを日付型にキャストし
無理だったら今日の日付を使うって仕様があったとする。
で、入力文字列をとりあえずそのままDate型にParseして、成功すればその値を使い
例外吐いたらキャッチして変わりに今日の日付を取得～ってコードを書く、とはせず
入力文字列を、パターンマッチとかつかって日付として認識できる文字列かを判定し、
問題ない場合だけParseする、っつーやり方。tryParseできる言語なら必要ないけどな
半端な知識で凝ったことやるとスパゲッティが完成するから気をつけてねミ☆
Booleanを戻りに持つメソッドはisで始めないといけないと勘違いしてるんでそ
結構勘違いしてる人いるよ。Bool格納する変数にisつけたりもよく見る
>>192
そもそもこの手の存在チェックって、チェック時点でOKになっても
実際に参照するときにOKである補償がないから、こういうメソッドって作る意味ないよ()笑
ましてやTesterのなかに例外処理入れてたら本末転倒。お勉強しなおしてくださいな
事前にテストするっつーのは、例えば
入力された文字列が日付に変換できる場合にはそれを日付型にキャストし
無理だったら今日の日付を使うって仕様があったとする。
で、入力文字列をとりあえずそのままDate型にParseして、成功すればその値を使い
例外吐いたらキャッチして変わりに今日の日付を取得～ってコードを書く、とはせず
入力文字列を、パターンマッチとかつかって日付として認識できる文字列かを判定し、
問題ない場合だけParseする、っつーやり方。tryParseできる言語なら必要ないけどな
半端な知識で凝ったことやるとスパゲッティが完成するから気をつけてねミ☆
>>201
ああ、理解したそりゃすまんかった
先にも書いてるけど、ファイルみたいな外部リソースは確認時点で存在したものが
いざ扱おうとしたときに存在している保証がないからから、
そのあたりにはTesterとなるメソッドを儲けるメリットがあんまないからじゃよ
スレッドで同期取ったり、DBで参照排他とかかけるのと同じで
ファイルが存在する状態を保持し続けるなら開いちまえばいいっていう
ああ、理解したそりゃすまんかった
先にも書いてるけど、ファイルみたいな外部リソースは確認時点で存在したものが
いざ扱おうとしたときに存在している保証がないからから、
そのあたりにはTesterとなるメソッドを儲けるメリットがあんまないからじゃよ
スレッドで同期取ったり、DBで参照排他とかかけるのと同じで
ファイルが存在する状態を保持し続けるなら開いちまえばいいっていう
>>197
そう。メソッドチェーンという名前が付いてる。
たとえばhibernateならこういう使い方をする。
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querysql.html
List loggedCats = sess.createSQLQuery(sql)
.addEntity("cat", Cat.class)
.addEntity("mother", Cat.class).list()
> v = hoge(hage(hige()))
もう、これが駄目な書き方とか、
そんなこと言っている時代じゃないんだよ。
見ての通りメソッドチェーンを使うと見やすくかけるし、
こういう書き方をするのは今の時代では常識。
しかもこれ、例外使った言語でしかまともに実装できないので
戻り値を使って頑張るとか、無駄な努力だよ。
そう。メソッドチェーンという名前が付いてる。
たとえばhibernateならこういう使い方をする。
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querysql.html
List loggedCats = sess.createSQLQuery(sql)
.addEntity("cat", Cat.class)
.addEntity("mother", Cat.class).list()
> v = hoge(hage(hige()))
もう、これが駄目な書き方とか、
そんなこと言っている時代じゃないんだよ。
見ての通りメソッドチェーンを使うと見やすくかけるし、
こういう書き方をするのは今の時代では常識。
しかもこれ、例外使った言語でしかまともに実装できないので
戻り値を使って頑張るとか、無駄な努力だよ。
IsExists（笑）
チェーンは行分けて書きやすいから、ステップ実行しやすいのもいいよね
例外とは関係ない話題だけど、メソッドチェーンも知らない人はほんと知らないよね
StringBuilder sb = new StringBuilder();
sb.append("ほげ");
sb.append(hoge);
sb.append("はげ");
sb.append(hage);
sb.append("おしまい");
こういうのとかも結構見かける
StringBuilder sb = new StringBuilder();
sb.append("ほげ");
sb.append(hoge);
sb.append("はげ");
sb.append(hage);
sb.append("おしまい");
こういうのとかも結構見かける
で、メソッドチェーン使ったらスタイリッシュになるの？
>>200
これ
tp://msdn.microsoft.com/ja-jp/library/microsoft.office.interop.word._application.documents
Documentsメンバの中にExistsとかContainsとかがねー
http://msdn.microsoft.com/ja-jp/library/microsoft.office.interop.word.documents_members%28v=office.11%29.aspx
あと、Wordが既に開いているはずだから
＞先にも書いてるけど、ファイルみたいな外部リソースは確認時点で存在したものが
＞いざ扱おうとしたときに存在している保証がないからから、
保証はあるような・・・気がする
これ
tp://msdn.microsoft.com/ja-jp/library/microsoft.office.interop.word._application.documents
Documentsメンバの中にExistsとかContainsとかがねー
http://msdn.microsoft.com/ja-jp/library/microsoft.office.interop.word.documents_members%28v=office.11%29.aspx
あと、Wordが既に開いているはずだから
＞先にも書いてるけど、ファイルみたいな外部リソースは確認時点で存在したものが
＞いざ扱おうとしたときに存在している保証がないからから、
保証はあるような・・・気がする
>>207
それぐらい自分で判断しろよ。
List loggedCats = sess.createSQLQuery(sql)
.addEntity("cat", Cat.class)
.addEntity("mother", Cat.class)
.list();
と
Query query = sess.createSQLQuery(sql);
query.addEntity("cat", Cat.class);
query.addEntity("mother", Cat.class);
List loggedCats = query.list();
行数は同じだから、どっちも同じだろ？ な？
それぐらい自分で判断しろよ。
List loggedCats = sess.createSQLQuery(sql)
.addEntity("cat", Cat.class)
.addEntity("mother", Cat.class)
.list();
と
Query query = sess.createSQLQuery(sql);
query.addEntity("cat", Cat.class);
query.addEntity("mother", Cat.class);
List loggedCats = query.list();
行数は同じだから、どっちも同じだろ？ な？
>>208
> Documentsメンバの中にExistsとかContainsとかがねー
> http://msdn.microsoft.com/ja-jp/library/microsoft.office.interop.word.documents_members%28v=office.11%29.aspx
これがあるじゃねーか。
> GetEnumerator コレクション全体での繰り返しをサポートするために、列挙型の値を取得します。
> Documentsメンバの中にExistsとかContainsとかがねー
> http://msdn.microsoft.com/ja-jp/library/microsoft.office.interop.word.documents_members%28v=office.11%29.aspx
これがあるじゃねーか。
> GetEnumerator コレクション全体での繰り返しをサポートするために、列挙型の値を取得します。
>>192
そもそも、ファイルの話じゃなかったのか？
そもそも、ファイルの話じゃなかったのか？
オマエラまだファイルの話してたのか
いや、メソッドチェーンの話だよ。
例外とは全く関係ないな
なんつーかもう戻り値と比較するのやめようぜ
昨今の環境やら言語やらで例外使えないなんてことはよほど特殊な場合をのぞいてないわけだし
正しく使う分にはデメリットなんぞない
比べること自体がナンセンス
昨今の環境やら言語やらで例外使えないなんてことはよほど特殊な場合をのぞいてないわけだし
正しく使う分にはデメリットなんぞない
比べること自体がナンセンス
しょーがねーだろ、いもしねぇ戻り値派とやらを脳内設定して
「俺って新しい、ジジィどもは例外についてこれない」
オナニーしたいだけのバカなんだし。
「俺って新しい、ジジィどもは例外についてこれない」
オナニーしたいだけのバカなんだし。
え？ 戻り値派が
書きこまなければ
いいだけだよね？
書きこまなければ
いいだけだよね？
新しモノ好きはこの仕事には必須だから、
いーんじゃねーのちょっとぐらい天狗になっても若いウチはw
25過ぎたあと自分がイタかったなぁと思い返せばすむことだ。
いーんじゃねーのちょっとぐらい天狗になっても若いウチはw
25過ぎたあと自分がイタかったなぁと思い返せばすむことだ。
223 ：仕様書無しさん：2011/02/08(火) 08:31:46
ぷっぷっぅぅぅぅぅぅぅぅぅぅぅ
メソッドチェーン?
sb.appendが?
おまいらほんとうに 馬鹿を通り越して 「見世物小屋」状態だな
いいぞ、どんどんやれよ
hoge()->unko(); みたいなイメージだとメソッドチェーンになるのかな
メソッドチェーン?
sb.appendが?
おまいらほんとうに 馬鹿を通り越して 「見世物小屋」状態だな
いいぞ、どんどんやれよ
hoge()->unko(); みたいなイメージだとメソッドチェーンになるのかな
自分より上位で例外をちゃんと処理してくれる事を期待するとか、発想が
先祖返りしてるような気がする。
プログラムが異常終了するかも知れないリスクを他の処理にも負わせる
とか、やっぱどこか変だ。
先祖返りしてるような気がする。
プログラムが異常終了するかも知れないリスクを他の処理にも負わせる
とか、やっぱどこか変だ。
>>224
例外で止まるのは異常終了と言うのか？どっちかというと緊急停止だろ。
例外で止まるのは異常終了と言うのか？どっちかというと緊急停止だろ。
フォールトトレラントって、最近はダメな発想なの？
例外握りつぶしてとりあえず落ちないのとはまた別の話だろ…
握りつぶしを良しとするヤツはいない。そんな趣旨でレスしてるヤツもいない。
想定外の異常を無視することはフォールトトレラントとは言わない。
じゃあ異常終了させた方がマシってかｗ
まれにくる特定パターンの入力を受けると想定外の例外を発生させる場合、
そのパターンの時だけ人手で処理するなんてのも考えられる。
そういう時に、そのパターンが来るたびにシステム全停止とかされると困る。
そのパターンの時だけ人手で処理するなんてのも考えられる。
そういう時に、そのパターンが来るたびにシステム全停止とかされると困る。
まあ、戻り値エラーも、上位でちゃんとエラー処理してくれることを期待して、エラー値を返すんだけどね。
ファイル見つからないからいきなり死亡ｗ
計算結果が想定の範囲外だったのでいきなり死亡ｗ
良かれと思って新しいタイプの例外作って誰も対処できないからすぐさま死亡ｗ
ほっときゃ正常に稼動してた部分まで巻き添えで死亡ｗｗｗ
使ってるヤツの都合とか考えず、開発者のオナニーで全部パァｗｗｗ
その場でソフト終了ｗｗｗ だってその方がカッチョイイからｗｗｗｗｗｗｗｗｗ
そんなんでいいのか？
計算結果が想定の範囲外だったのでいきなり死亡ｗ
良かれと思って新しいタイプの例外作って誰も対処できないからすぐさま死亡ｗ
ほっときゃ正常に稼動してた部分まで巻き添えで死亡ｗｗｗ
使ってるヤツの都合とか考えず、開発者のオナニーで全部パァｗｗｗ
その場でソフト終了ｗｗｗ だってその方がカッチョイイからｗｗｗｗｗｗｗｗｗ
そんなんでいいのか？
>>233
それでいいよ。
っていうか、なんでだめ？
あんたは自分の作ったプログラムに
自信がないのか？
落ちるのは異常状態の場合だけ、
異常状態になんかしないから
落ちることはない。
異常状態になって落ちたらどうしようなんて怖がってるのは、
自分の作ったプログラムが落ちると思っているからだろ。
それでいいよ。
っていうか、なんでだめ？
あんたは自分の作ったプログラムに
自信がないのか？
落ちるのは異常状態の場合だけ、
異常状態になんかしないから
落ちることはない。
異常状態になって落ちたらどうしようなんて怖がってるのは、
自分の作ったプログラムが落ちると思っているからだろ。
>>233
＞ファイルが見つからないから
たとえば、設定ファイルが見つからないのなら、
警告メッセージを出したうえで（UIかログファイルか、など詳細は状況依存）
デフォルト設定で処理継続するとかの手段がある。
もちろん、処理継続の手段は一つではない。
＞ほっときゃ正常に稼動してた部分まで巻き添えで死亡ｗｗｗ
問題は『想定外』の例外が起こった場合。
想定外なので、当然正常に稼働していた部分が、これからも正常に稼働し続けるという保証はない。
もちろん、想定外の場合でも、想定外の内容によるがな。
たとえば、上記の設定ファイルが見つからないレベルなら、
場合によってはデフォルト設定で継続しても問題ないかもしれん。
ただし、警告メッセージは必須。
＞ファイルが見つからないから
たとえば、設定ファイルが見つからないのなら、
警告メッセージを出したうえで（UIかログファイルか、など詳細は状況依存）
デフォルト設定で処理継続するとかの手段がある。
もちろん、処理継続の手段は一つではない。
＞ほっときゃ正常に稼動してた部分まで巻き添えで死亡ｗｗｗ
問題は『想定外』の例外が起こった場合。
想定外なので、当然正常に稼働していた部分が、これからも正常に稼働し続けるという保証はない。
もちろん、想定外の場合でも、想定外の内容によるがな。
たとえば、上記の設定ファイルが見つからないレベルなら、
場合によってはデフォルト設定で継続しても問題ないかもしれん。
ただし、警告メッセージは必須。
どうも前提がわかってないみたいだね。
例外で落ちるとか言うが、いきなり落ちるわけじゃない。
落ちる前に原因がある
その原因というのが、想定外の自体が起きて異常状態になった場合。
想定外なのだから、無視していいかどうか分からない。
さて、「無視していいかどうか分からない異常事態が発生しました」
この場合、戻り値だとエラーチェックを書かなければ
異常事態のまま続行してしまう。
例外だと何も書かなくても異常事態のとき停止する。
ここまで詳しくかけば、例外のほうが異常事態の時安全だとわかるだろう。
これでわからなければ、本当のばかだよ。
例外で落ちるとか言うが、いきなり落ちるわけじゃない。
落ちる前に原因がある
その原因というのが、想定外の自体が起きて異常状態になった場合。
想定外なのだから、無視していいかどうか分からない。
さて、「無視していいかどうか分からない異常事態が発生しました」
この場合、戻り値だとエラーチェックを書かなければ
異常事態のまま続行してしまう。
例外だと何も書かなくても異常事態のとき停止する。
ここまで詳しくかけば、例外のほうが異常事態の時安全だとわかるだろう。
これでわからなければ、本当のばかだよ。
>>223
> メソッドチェーン?
> sb.appendが?
sunのドキュメントでもappendはメソッドチェーンであるように書かれてるよ
http://java.sun.com/j2se/1.3/ja/docs/ja/api/java/text/Format.html
> 戻り値:
> toAppendTo として渡される値 (これによって、StringBuffer.append() と同じようにチェーンが可能になる)
> メソッドチェーン?
> sb.appendが?
sunのドキュメントでもappendはメソッドチェーンであるように書かれてるよ
http://java.sun.com/j2se/1.3/ja/docs/ja/api/java/text/Format.html
> 戻り値:
> toAppendTo として渡される値 (これによって、StringBuffer.append() と同じようにチェーンが可能になる)
国際宇宙ステーションの生命維持装置が、想定外の異常発生のため全停止ｗ
新幹線のダイヤ管理システムが、想定外の事象発生のため全停止ｗｗｗ
そんなのは、嫌だｗ
新幹線のダイヤ管理システムが、想定外の事象発生のため全停止ｗｗｗ
そんなのは、嫌だｗ
>>238
新幹線が異常事態で停止しないほうがコワイってｗ
新幹線が異常事態で停止しないほうがコワイってｗ
そうそう、いい忘れたけど、異常事態で停止するのは
デフォルトであって、例外なら異常事態でも
正常に動き続けることも可能。
戻り値だと異常事態から復旧することが
極めて難しいけど、
例外だと復旧処理をまとめることが可能なので
異常事態が起きても安全になる。
デフォルトであって、例外なら異常事態でも
正常に動き続けることも可能。
戻り値だと異常事態から復旧することが
極めて難しいけど、
例外だと復旧処理をまとめることが可能なので
異常事態が起きても安全になる。
打ち上げ直後に想定外の異常発生のため、ロケット制御システムが全停止ｗ
小惑星探査機の制御システムで、想定外の異常が発生してシステムが全停止ｗ
ペースメーカーの制御システムが、想定外の事象発生のため全停止ｗ
小惑星探査機の制御システムで、想定外の異常が発生してシステムが全停止ｗ
ペースメーカーの制御システムが、想定外の事象発生のため全停止ｗ
240=236でOK？
なんで戻り値と比較してるの？
なんで戻り値と比較してるの？
>>241
わざわざ停止したらまずいものを考えなくていいってｗ
お前に反論するのも簡単だよ。
ガスコンロ、異常事態で停止するのが安全。
電子力発電所、異常事態で停止するのが安全。
打ち上げ直前のロケット制御システム、異常事態で停止するのが安全。
離陸前の飛行機、異常事態で停止するのが安全。
お前が言ってるのはすぐに停止するのがまずいものだけだろ。
世の中異常事態で停止するほうが多いよ。
動き続けなきゃいけないものも、異常事態を無視してるわけじゃないだろ。
わざわざ停止したらまずいものを考えなくていいってｗ
お前に反論するのも簡単だよ。
ガスコンロ、異常事態で停止するのが安全。
電子力発電所、異常事態で停止するのが安全。
打ち上げ直前のロケット制御システム、異常事態で停止するのが安全。
離陸前の飛行機、異常事態で停止するのが安全。
お前が言ってるのはすぐに停止するのがまずいものだけだろ。
世の中異常事態で停止するほうが多いよ。
動き続けなきゃいけないものも、異常事態を無視してるわけじゃないだろ。
StringBuffer.append()
これスタティックメソッドって知っている?
これスタティックメソッドって知っている?
>>239
異常停止したら停止するわけじゃないけどな。
異常停止したら停止するわけじゃないけどな。
>>236
ま、誰かが止めたら止まらなくなっちゃうんだけどねｗ
ま、誰かが止めたら止まらなくなっちゃうんだけどねｗ
＞＞244
スタティックメソッドには、staticって書くんだよ。
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/Integer.html#valueOf(java.lang.String)
public static Integer valueOf(String s) throws NumberFormatException
^^^^^^^^^
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/StringBuffer.html#append(java.lang.String)
> public StringBuffer append(String str)
スタティックメソッドには、staticって書くんだよ。
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/Integer.html#valueOf(java.lang.String)
public static Integer valueOf(String s) throws NumberFormatException
^^^^^^^^^
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/StringBuffer.html#append(java.lang.String)
> public StringBuffer append(String str)
ねぇねぇ、バカやっちゃってるけど
今どんな気持ち？
∩＿＿＿∩ ∩＿＿＿∩
♪ | ノ ⌒ ⌒ヽﾊｯ __ _,, -ー ,, ﾊｯ / ⌒ ⌒ 丶|
/ (●) (●) ﾊｯ (／ "つ`..,： ﾊｯ (●) (●) 丶 戻り値厨、どんな気持ち？
| ( _●_) ミ ：/ >>244 :::::i：. ミ (_●_ ) | 戻り値厨、どんな気持ち？
＿＿＿ 彡 |∪| ミ ：i ─::!,, ミ､ |∪| ､彡＿＿__
ヽ＿＿＿ ヽノ､｀＼ ヽ.....::::::::: ::::ij(_::● / ヽノ ＿＿＿/
/ ／ヽ < r " .r ミノ~. 〉 ／＼ 丶
/ ／ ￣ ：|::| ::::| :::i ﾟ。 ￣♪ ＼ 丶
/ ／ ♪ ：|::| ::::| :::|： ＼ 丶
（＿ ⌒丶... ：` | ::::| :::|_： /⌒＿）
| /ヽ }. ：.,' ::（ :::} } ﾍ /
し ））. ：:i `.-‐" J´（（
ｿ ﾄﾝﾄﾝ ｿ ﾄﾝﾄﾝ
今どんな気持ち？
∩＿＿＿∩ ∩＿＿＿∩
♪ | ノ ⌒ ⌒ヽﾊｯ __ _,, -ー ,, ﾊｯ / ⌒ ⌒ 丶|
/ (●) (●) ﾊｯ (／ "つ`..,： ﾊｯ (●) (●) 丶 戻り値厨、どんな気持ち？
| ( _●_) ミ ：/ >>244 :::::i：. ミ (_●_ ) | 戻り値厨、どんな気持ち？
＿＿＿ 彡 |∪| ミ ：i ─::!,, ミ､ |∪| ､彡＿＿__
ヽ＿＿＿ ヽノ､｀＼ ヽ.....::::::::: ::::ij(_::● / ヽノ ＿＿＿/
/ ／ヽ < r " .r ミノ~. 〉 ／＼ 丶
/ ／ ￣ ：|::| ::::| :::i ﾟ。 ￣♪ ＼ 丶
/ ／ ♪ ：|::| ::::| :::|： ＼ 丶
（＿ ⌒丶... ：` | ::::| :::|_： /⌒＿）
| /ヽ }. ：.,' ::（ :::} } ﾍ /
し ））. ：:i `.-‐" J´（（
ｿ ﾄﾝﾄﾝ ｿ ﾄﾝﾄﾝ
いやいや、newしたオブジェクト
StringBuffer sb = new StringBuffer();
sb.append()のように書くのじゃないの?
知らんけど
StringBuffer.append() だとstatic で使えるの?
Integer.parseInt()はスタティックだよねたしか
俺よく知らんのですまんけど教えて
StringBuffer sb = new StringBuffer();
sb.append()のように書くのじゃないの?
知らんけど
StringBuffer.append() だとstatic で使えるの?
Integer.parseInt()はスタティックだよねたしか
俺よく知らんのですまんけど教えて
>>206ぐらい読んだだろうに、
> StringBuilder sb = new StringBuilder();
> sb.append("ほげ");
これがstaticメソッドなら、"ほげ" は
なんに対して、appendしたのか疑問にならなかったのか？ｗ
どうもオブジェクト指向の初歩もしらんようだな。
どおりで例外も知らんわけだ。
> StringBuilder sb = new StringBuilder();
> sb.append("ほげ");
これがstaticメソッドなら、"ほげ" は
なんに対して、appendしたのか疑問にならなかったのか？ｗ
どうもオブジェクト指向の初歩もしらんようだな。
どおりで例外も知らんわけだ。
>>206 あったんだねえ。そうか俺VBしかしらんから。すまんかった。
帰ります。
帰ります。
いまさらJavaはやめたほうがいいとおもうけどなぁ。
むしろプログラマ自体やめとけ
スレタイ
いや、俺ここにきてがぜんJavaやる気になりました。
static void main(String args){
int cnt=0;
for(;;){
System.out.print("VBマン");
if(cnt++ % 2){
Sytem.out.println();
}else if(cnt > (10 * 10 * 10)){
break;
}
}
}
static void main(String args){
int cnt=0;
for(;;){
System.out.print("VBマン");
if(cnt++ % 2){
Sytem.out.println();
}else if(cnt > (10 * 10 * 10)){
break;
}
}
}
例外の話していても、なぜか戻り値厨がからんでくるからなぁ。
例外の話しかしないから、絡んでくるなよ。
例外は基本ホワイトリスト方式で、catchに書いたもののみエラーを無視する。
安全だと明記されないエラーはすべて異常と判断する。
どんな異常事態でも、適切に動作させるにはそのようなコードを書かないといけない。
異常事態が発生したとき、何も書かなければ終了。
書いてあれば動作を続けるという安全な方法。
だから、この安全性をムダにするような書き方は例外の使い方とした正しくない。
たとえば、例外をトラップして、true/falseに変換するような書き方は
異常事態が発生しても、（チェックしなければ）動作を続けるわけで正しくない書き方。
例外の話しかしないから、絡んでくるなよ。
例外は基本ホワイトリスト方式で、catchに書いたもののみエラーを無視する。
安全だと明記されないエラーはすべて異常と判断する。
どんな異常事態でも、適切に動作させるにはそのようなコードを書かないといけない。
異常事態が発生したとき、何も書かなければ終了。
書いてあれば動作を続けるという安全な方法。
だから、この安全性をムダにするような書き方は例外の使い方とした正しくない。
たとえば、例外をトラップして、true/falseに変換するような書き方は
異常事態が発生しても、（チェックしなければ）動作を続けるわけで正しくない書き方。
で、それには３２ビットプロセッサが必要なワケだｗ
ああ、言語の例外機構を実装するためにはなｗ
普通にOCPを考えてプログラムを書いたら
リカバリーやリソース保護の例外ぐらいしか書かないものだが。
リカバリーやリソース保護の例外ぐらいしか書かないものだが。
ヒント、ここの奴らは普通以下だからｗ
わたしのビット数は５３００００です。
ＣＰＵに保護機構は必要だよなｗ
(new StringBuilder(hoge)).append("ほげ")
.append(hage).append("は、ハゲちゃうわ").toString();
.append(hage).append("は、ハゲちゃうわ").toString();
戻り値を正しく使えない奴は、例外使っても同じ
エラー制御面倒だから、全部tryでくくっちゃえ程度の認識なんだろ？
エラー制御面倒だから、全部tryでくくっちゃえ程度の認識なんだろ？
いや、例外を使えば
> v = hoge(hage(hige()))
みたいな書き方やめそっどちぇーんのような
効率的でコストの低いコードが使える。
頭の古い戻り値派には理解できないだろうが、これは16ビット時代では難しかった
つまり例外とは割り込み処理だ他のタスクに影響を与えないような
保護機能が備わっているCPU上で実装されている。だが、
言語の例外処理機構の実装にCPU例外は関係ない。当然CPU割り込みも関係ない。
俺が言っているのは言語の例外機構だ。
とにかく。例外は最新技術だから戻り値派のおっさんどもにはついて来れないだろう。
オレにもついて行けないｗ
> v = hoge(hage(hige()))
みたいな書き方やめそっどちぇーんのような
効率的でコストの低いコードが使える。
頭の古い戻り値派には理解できないだろうが、これは16ビット時代では難しかった
つまり例外とは割り込み処理だ他のタスクに影響を与えないような
保護機能が備わっているCPU上で実装されている。だが、
言語の例外処理機構の実装にCPU例外は関係ない。当然CPU割り込みも関係ない。
俺が言っているのは言語の例外機構だ。
とにかく。例外は最新技術だから戻り値派のおっさんどもにはついて来れないだろう。
オレにもついて行けないｗ
>>267 コピペ貼り合わせおもしろくない
269 ：VBマン：2011/02/09(水) 09:33:56
import java.io.*;
class Vbman{
static final String endl = "\r\n";
public static void main(String ag[]){
String hoge = "hoge";
int i=0;
byte[] hige;
try{
FileOutputStream fo = new FileOutputStream("./hoge.txt");
//FilterWriter fw = new FilterWriter(fo);
while(true){
hoge = hoge.concat("unko");
i++;
if((i/9999)==0){
i=0;
System.out.print("〓"+hoge);
hige = hoge.getBytes("UTF-8");
fo.write(hige);
fo.flush();
}
System.out.print(endl);
}
}catch(Exception e){
}finally{
}
}
}
javaおもしろいっす
class Vbman{
static final String endl = "\r\n";
public static void main(String ag[]){
String hoge = "hoge";
int i=0;
byte[] hige;
try{
FileOutputStream fo = new FileOutputStream("./hoge.txt");
//FilterWriter fw = new FilterWriter(fo);
while(true){
hoge = hoge.concat("unko");
i++;
if((i/9999)==0){
i=0;
System.out.print("〓"+hoge);
hige = hoge.getBytes("UTF-8");
fo.write(hige);
fo.flush();
}
System.out.print(endl);
}
}catch(Exception e){
}finally{
}
}
}
javaおもしろいっす
270 ：VBマン：2011/02/09(水) 10:08:06
//Copyright(C) Vbman All right reserves.
import java.io.*;
import java.nio.*;
class Vbman2{
static final String endl = "\r\n";
public static void main(String hage[]){
ByteBuffer directBuffer[] = new ByteBuffer[1000];
int prm = 2147483647;
try{
for(int i=0; i<1000; i++){
directBuffer[i] = ByteBuffer.allocate(prm);
}
}catch(Exception e){
e.printStackTrace();
}finally{
}
}
}
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:39)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:312)
at Vbman2.main(Vbman2.java:14)
最高っす
import java.io.*;
import java.nio.*;
class Vbman2{
static final String endl = "\r\n";
public static void main(String hage[]){
ByteBuffer directBuffer[] = new ByteBuffer[1000];
int prm = 2147483647;
try{
for(int i=0; i<1000; i++){
directBuffer[i] = ByteBuffer.allocate(prm);
}
}catch(Exception e){
e.printStackTrace();
}finally{
}
}
}
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:39)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:312)
at Vbman2.main(Vbman2.java:14)
最高っす
open closeは隠ぺいできるがtry catch構文のスコープが嫌だな
Exceptionをイベントハンドラにすると上に投げられないけど
try {
..File file = new File("sexml.xml");
..Result r = new Session(file){
....private void invoke(XmlReader reader){
......XmlNode root = reader.getRoot();
......super.result(root);
....}
..};
..XmlNode root = (XmlNode)r.get();
} catch (IOException e){
..//
}
Exceptionをイベントハンドラにすると上に投げられないけど
try {
..File file = new File("sexml.xml");
..Result r = new Session(file){
....private void invoke(XmlReader reader){
......XmlNode root = reader.getRoot();
......super.result(root);
....}
..};
..XmlNode root = (XmlNode)r.get();
} catch (IOException e){
..//
}
272 ：仕様書無しさん：2011/02/09(水) 12:39:46
例外厨は多分、気軽に終了できるプログラムしか開発したことが
ないんだろうな。
データベースからレコードセット引っ張り出して、それを元に
ブラウザに表示するとかだったら、そもそも誰も本質的に必要じゃ
ないから、人知れず異常終了しても誰も困らないもんな。
スペランカー並のひ弱な作りで許されるんだろうよ。
ないんだろうな。
データベースからレコードセット引っ張り出して、それを元に
ブラウザに表示するとかだったら、そもそも誰も本質的に必要じゃ
ないから、人知れず異常終了しても誰も困らないもんな。
スペランカー並のひ弱な作りで許されるんだろうよ。
アンチ例外厨じゃなくて？
274 ：仕様書無しさん：2011/02/09(水) 13:27:57
import java.nio.*;
class Vbman3{
static final String endl = "\r\n";
static int i=0;
public static void main(String hage[]){
ByteBuffer directBuffer[] = new ByteBuffer[1000];
//int prm = 2147483647;
int prm= 4096*10*10*10;
try{
for(i=0; i<1000; i++){
System.out.println("メモリ確保=" + i + "回目");
directBuffer[i] = ByteBuffer.allocate(prm);
}
}catch(Exception e){
e.printStackTrace();
System.out.println("メモリ確保=" + i + "回目");
}finally{
}
}
}
メモリ確保=16回目
メモリ確保=17回目
メモリ確保=18回目
メモリ確保=19回目
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:39)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:312)
at Vbman3.main(Vbman3.java:17)
class Vbman3{
static final String endl = "\r\n";
static int i=0;
public static void main(String hage[]){
ByteBuffer directBuffer[] = new ByteBuffer[1000];
//int prm = 2147483647;
int prm= 4096*10*10*10;
try{
for(i=0; i<1000; i++){
System.out.println("メモリ確保=" + i + "回目");
directBuffer[i] = ByteBuffer.allocate(prm);
}
}catch(Exception e){
e.printStackTrace();
System.out.println("メモリ確保=" + i + "回目");
}finally{
}
}
}
メモリ確保=16回目
メモリ確保=17回目
メモリ確保=18回目
メモリ確保=19回目
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:39)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:312)
at Vbman3.main(Vbman3.java:17)
275 ：仕様書無しさん：2011/02/09(水) 13:32:17
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/nio/ByteBuffer.html#allocate(int)
ByteBuffer.allocate(prm)の戻り値はNULLとかならないんだね
Cのmallocの実装とちがって、むりくりExceptionってどうも
例外をきちんと処理できないと終了しかないよね
ByteBuffer.allocate(prm)の戻り値はNULLとかならないんだね
Cのmallocの実装とちがって、むりくりExceptionってどうも
例外をきちんと処理できないと終了しかないよね
276 ：仕様書無しさん：2011/02/09(水) 13:38:27
回数の表示位置もいいかげんだけど、tryの中で宣言したiをcatchの中でみるために
static int化するんだけど、この時点でスレッドアンセーフ確定だな
catch(引数 **argv)みたいにiを渡せないの?
static int化するんだけど、この時点でスレッドアンセーフ確定だな
catch(引数 **argv)みたいにiを渡せないの?
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/Error.html
>Error は Throwable のサブクラスで、通常のアプリケーションであればキャッチすべきではない重大な問題を示します。
>キャッチすべきではない
>キャッチすべきではない
>キャッチすべきではない
>Error は Throwable のサブクラスで、通常のアプリケーションであればキャッチすべきではない重大な問題を示します。
>キャッチすべきではない
>キャッチすべきではない
>キャッチすべきではない
通常のアプリケーションであれば、な。
いいんじゃねーの？
いいんじゃねーの？
自分が放り投げた例外が、取って欲しくない奴に取られたらどうするんだろ
自分の投げた例外で、プログラムが破滅的な状態になっても構わない（ｷﾘｯ
プログラムが壊滅的な状態になるような入力を与えた方が悪い
そもそも、例外が投げられた時点で、大抵は、
処理を続行できないか、続行しても意味の無い値が出力されるか、いずれ異常終了するか、
のどれかの状態なんだけどね。
>自分の投げた例外で、プログラムが破滅的な状態になっても構わない(ｷﾘｯ
(ｷﾘｯ
例外が投げられた時、プログラムが破滅的になったとしたら、
それは使う側(受け取る側)が、プログラムが破滅的になる処理(もしくは放置)を書いたからで、
使われる側や例外処理機構は関係ないのです。
処理を続行できないか、続行しても意味の無い値が出力されるか、いずれ異常終了するか、
のどれかの状態なんだけどね。
>自分の投げた例外で、プログラムが破滅的な状態になっても構わない(ｷﾘｯ
(ｷﾘｯ
例外が投げられた時、プログラムが破滅的になったとしたら、
それは使う側(受け取る側)が、プログラムが破滅的になる処理(もしくは放置)を書いたからで、
使われる側や例外処理機構は関係ないのです。
そのセリフ、職業プログラマではないな
>>286 なぜそうなる？
手前勝手な実装をして、それをフォローしなかったら他者が悪いとか言うところとか、
社会人やってたら最低限身に付いてるであろう社会常識に欠けてるから。
社会人やってたら最低限身に付いてるであろう社会常識に欠けてるから。
つまり、例外はその場で握りつぶせ、と。
>>291
そういう余計な事を付け足す姿勢、プログラマから嫌われますよ？
そういう余計な事を付け足す姿勢、プログラマから嫌われますよ？
>余計な事には手を出さない方が、勝手が良い
ホントにな。
例外に乗っけてるテキストメッセージを
そのままダイアログでユーザに見せるとかアホかっつーの。
その上「画面仕様変わったのでテキスト変えて下さい」だと？
マジしね。
3回ぐらいしね。
ホントにな。
例外に乗っけてるテキストメッセージを
そのままダイアログでユーザに見せるとかアホかっつーの。
その上「画面仕様変わったのでテキスト変えて下さい」だと？
マジしね。
3回ぐらいしね。
isResult = FileOpen()
if(isResult){
//エラーメッセージ
//エラー処理
return;
}
例えば戻り値でファイル開く処理するとこんもんだろうが、
FF１４だとファイルだけで１３万ファイルあるという。
１ファイルで６行も使うとそれだで１００万行消費する。
だから例外でソース行数を短縮する必要があるんだよ。
if(isResult){
//エラーメッセージ
//エラー処理
return;
}
例えば戻り値でファイル開く処理するとこんもんだろうが、
FF１４だとファイルだけで１３万ファイルあるという。
１ファイルで６行も使うとそれだで１００万行消費する。
だから例外でソース行数を短縮する必要があるんだよ。
共通にできそうな処理は関数化すればいいじゃん
例外で短くなる理由になってないような？
例外で短くなる理由になってないような？
throw投げまくるのってどうなんだろ。
例外クラス二つほど作って、キャッチも二つほど用意しておくと
コードはとても見やすくなるんだけど。
if山嫌だし。。
例外クラス二つほど作って、キャッチも二つほど用意しておくと
コードはとても見やすくなるんだけど。
if山嫌だし。。
>>297
throw投げまくるって、言葉としておかしくね？
throw投げまくるって、言葉としておかしくね？
そもそも、処理が続行できるかどうかもわからない
異常事態が起きたのだから、落とすのは正しい。
続行できるかどうかもわからない状態で続行してはいけない。
異常事態が起きたのだから、落とすのは正しい。
続行できるかどうかもわからない状態で続行してはいけない。
異常事態でもないのに例外投げる馬鹿がいなけりゃいいんだけどな。
MVC
Mは引数が少しでもおかしい時は即、例外発生させてます。
CはMのメソッドの引数になる値がによって、Mのメソッドを呼び出すか呼び出さないか、
もしくはMの何のメソッドを呼び出すかといった事をやってます。
CからMのメソッド呼び出し時でデータ更新処理をしたりする時は
tryで括って例外補足しています。補足時は例外のエラーコードに合わせて、
処理を分岐させています。
私はおかしいでしょうか？普通でしょうか？
キャリアが短いのと勤めているわけではない素人なので、
あまり人のソースコードを見たことがないため不安です。
上記文章を読んでどのような感想をもたれたのか、一言どうぞ。
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Mは引数が少しでもおかしい時は即、例外発生させてます。
CはMのメソッドの引数になる値がによって、Mのメソッドを呼び出すか呼び出さないか、
もしくはMの何のメソッドを呼び出すかといった事をやってます。
CからMのメソッド呼び出し時でデータ更新処理をしたりする時は
tryで括って例外補足しています。補足時は例外のエラーコードに合わせて、
処理を分岐させています。
私はおかしいでしょうか？普通でしょうか？
キャリアが短いのと勤めているわけではない素人なので、
あまり人のソースコードを見たことがないため不安です。
上記文章を読んでどのような感想をもたれたのか、一言どうぞ。
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
自身が復旧できない状態なら例外投げてくれ
あっちこっちにむりくり変換したりする馬鹿がいると一気に破綻する
あっちこっちにむりくり変換したりする馬鹿がいると一気に破綻する
305 ：仕様書無しさん：2011/02/10(木) 07:48:55
大したことないのに大騒ぎして、誰も相手しなかったらプログラムを
道連れにして自爆。
結論：例外厨は迷惑
道連れにして自爆。
結論：例外厨は迷惑
例外は道連れ自爆犯
戻り値は隠れたテロリスト
そろそろ新しいエラー処理方法を考えたほうがいいんじゃね？
戻り値は隠れたテロリスト
そろそろ新しいエラー処理方法を考えたほうがいいんじゃね？
結論:>>305はバカ
例外が起きたら、その時に対処して、なるべく他の処理への影響を
少なくした方がいいんじゃないの？
例えば、ファイル読出処理にとっては、対象ファイルがないのは天地が
ひっくり返る程の事態かも知れないけど、他の処理にしてみれば、
それで無理心中させられたらたまったもんじゃないわな。
自分の都合しか考えられない欠陥人間が、例外機構を異常にプッシュ
している予感・・・
少なくした方がいいんじゃないの？
例えば、ファイル読出処理にとっては、対象ファイルがないのは天地が
ひっくり返る程の事態かも知れないけど、他の処理にしてみれば、
それで無理心中させられたらたまったもんじゃないわな。
自分の都合しか考えられない欠陥人間が、例外機構を異常にプッシュ
している予感・・・
例外使いに質問じゃ
メソッド
int Method1()
は仕様上1～5までのint値を返すべしと定義されている。
メソッド
void Method2(int)
は仕様上1～10までのint値の入力が可能と定義されている。
ここで、
Method3() {
int t = Method1();
// tに6が返ってきた。
Method2(t);
}
のように、Method1にバグがあり6を返したとする。
さて、この場合Method1、Method3はどうするべきだろうか？
（ただし、Method2は色々な場所で使用されており、他の場所では6～10の値も入力される可能性があるとする）
俺が考えるにいくつかのパターンがあると思っていて……
(1) Method1、Method3ともに何もしない。
(2) Method1のしかるべき場所（return直前など）に値のチェックを入れる。
→ここで仕様外の値returnされそうな場合は例外を出す。
少なくともMethod3は何もしちゃならんとは思っているのだが……Method1はどうすべきなんだろうか。
一々チェックロジックをいれるのも面倒だしなぁ。
メソッド
int Method1()
は仕様上1～5までのint値を返すべしと定義されている。
メソッド
void Method2(int)
は仕様上1～10までのint値の入力が可能と定義されている。
ここで、
Method3() {
int t = Method1();
// tに6が返ってきた。
Method2(t);
}
のように、Method1にバグがあり6を返したとする。
さて、この場合Method1、Method3はどうするべきだろうか？
（ただし、Method2は色々な場所で使用されており、他の場所では6～10の値も入力される可能性があるとする）
俺が考えるにいくつかのパターンがあると思っていて……
(1) Method1、Method3ともに何もしない。
(2) Method1のしかるべき場所（return直前など）に値のチェックを入れる。
→ここで仕様外の値returnされそうな場合は例外を出す。
少なくともMethod3は何もしちゃならんとは思っているのだが……Method1はどうすべきなんだろうか。
一々チェックロジックをいれるのも面倒だしなぁ。
>>309
って、>>311みたいな回答が欲しい訳じゃないか。
まあ、俺だったら、一度検査するコードを書いたら、それ以降は忘れていられるように、
Methot1のreturn前に検査するコードを入れるかな。（returnがされている度にコードを書く必要があるが、Method1を使うたびに書くよりはマシさ。）
って、>>311みたいな回答が欲しい訳じゃないか。
まあ、俺だったら、一度検査するコードを書いたら、それ以降は忘れていられるように、
Methot1のreturn前に検査するコードを入れるかな。（returnがされている度にコードを書く必要があるが、Method1を使うたびに書くよりはマシさ。）
他に考えられる方法は・・・
・単体テストのコードをしっかり書いて、Method1のバグを見つける
・契約プログラミング（使える言語限られるけど）
・単体テストのコードをしっかり書いて、Method1のバグを見つける
・契約プログラミング（使える言語限られるけど）
>>309
定義が異なる値をint型で使いまわしているのがバグ
定義が異なる値をint型で使いまわしているのがバグ
かいとうありがとう！
>>313
> ・単体テストのコードをしっかり書いて、Method1のバグを見つける
単体テストではバグを見つけることができても、バグがないことは証明できないのよね。
定理証明でも使うか。。。この程度で。。。違うわなぁ
> ・契約プログラミング（使える言語限られるけど）
これが現実的かなぁ
>>313
> ・単体テストのコードをしっかり書いて、Method1のバグを見つける
単体テストではバグを見つけることができても、バグがないことは証明できないのよね。
定理証明でも使うか。。。この程度で。。。違うわなぁ
> ・契約プログラミング（使える言語限られるけど）
これが現実的かなぁ
例外厨の言ってることは、しょーもない事でわざわざ部長や
更に上まで事態収集の直談判しに行くようなものだな。
更に上まで事態収集の直談判しに行くようなものだな。
>>321
人間社会では迷惑ですけど、
プログラミングの世界では、些細な事でも知らせてくれた方が助かります。
知らせずにその場で処理する事もできますし。
むしろ、誰か一人のせいで、重要な事が知らされ無くなる、戻り値エラーの方法は問題です。
それにしても、戻り値エラーの方法だと、しょーもない事しか扱わないのでしょうか？
人間社会では迷惑ですけど、
プログラミングの世界では、些細な事でも知らせてくれた方が助かります。
知らせずにその場で処理する事もできますし。
むしろ、誰か一人のせいで、重要な事が知らされ無くなる、戻り値エラーの方法は問題です。
それにしても、戻り値エラーの方法だと、しょーもない事しか扱わないのでしょうか？
いや、だからどうして戻り値の話するのさ
社長的には、平社員から直接「バグ出してしまったんですけど」って報告されたら
部長・課長・チームリーダは何やってるんだ？って思うわな。
部長・課長・チームリーダは何やってるんだ？って思うわな。
もしくは社員数人の小さな会社か。
人間社会なら、ね。
コンピューターは感情なんて持たないんです。
コンピューターは感情なんて持たないんです。
例外の話していても、なぜか戻り値厨がからんでくるからなぁ。
例外の話しかしないから、絡んでくるなよ。
例外は基本ホワイトリスト方式で、catchに書いたもののみエラーを無視する。
安全だと明記されないエラーはすべて異常と判断する。
どんな異常事態でも、適切に動作させるにはそのようなコードを書かないといけない。
異常事態が発生したとき、何も書かなければ終了。
書いてあれば動作を続けるという安全な方法。
だから、この安全性をムダにするような書き方は例外の使い方とした正しくない。
たとえば、例外をトラップして、true/falseに変換するような書き方は
異常事態が発生しても、（チェックしなければ）動作を続けるわけで正しくない書き方。
例外の話しかしないから、絡んでくるなよ。
例外は基本ホワイトリスト方式で、catchに書いたもののみエラーを無視する。
安全だと明記されないエラーはすべて異常と判断する。
どんな異常事態でも、適切に動作させるにはそのようなコードを書かないといけない。
異常事態が発生したとき、何も書かなければ終了。
書いてあれば動作を続けるという安全な方法。
だから、この安全性をムダにするような書き方は例外の使い方とした正しくない。
たとえば、例外をトラップして、true/falseに変換するような書き方は
異常事態が発生しても、（チェックしなければ）動作を続けるわけで正しくない書き方。
そもそも、処理が続行できるかどうかもわからない異常事態が
起きたのだから、落とすのは正しい。
続行できるかどうかもわからない状態で続行してはいけない。
起きたのだから、落とすのは正しい。
続行できるかどうかもわからない状態で続行してはいけない。
じゃあ、ファイル読み込みをミスった程度で例外を投げるのは言語道断だよね
>>326
プログラム書くのは人間だけどね。
プログラム書くのは人間だけどね。
>>327
わざわざ戻り値の話してるのは君なんだけど。
わざわざ戻り値の話してるのは君なんだけど。
>>329
意味が分からない。
例外＝落ちる じゃないんだけど。
世の中例外でても落ちないことのほうが多い。
ちゃんとエラーチェックしているからね。
エラーチェックをちゃんとすれば例外でてもおちません。
それともお前はエラーチェックをしない人なのか？笑
意味が分からない。
例外＝落ちる じゃないんだけど。
世の中例外でても落ちないことのほうが多い。
ちゃんとエラーチェックしているからね。
エラーチェックをちゃんとすれば例外でてもおちません。
それともお前はエラーチェックをしない人なのか？笑
>>328に言ってくれ。
>>333
お前は「処理が続行できるかどうか分からない異常事態」と
書いてあるのが読めないのか？
>>328のどこに例外の話だって書いてあるんだよ？
処理が続行できると分かっているのなら、続行させればいい。
わかってないんだよ。いいか続行できるかわかってない異常事態なんだよ。
そういうのは、さっさと落としてからプログラムを修正しろ。
お前は「処理が続行できるかどうか分からない異常事態」と
書いてあるのが読めないのか？
>>328のどこに例外の話だって書いてあるんだよ？
処理が続行できると分かっているのなら、続行させればいい。
わかってないんだよ。いいか続行できるかわかってない異常事態なんだよ。
そういうのは、さっさと落としてからプログラムを修正しろ。
>>334
例外と関係ない話を力説されても。
例外と関係ない話を力説されても。
335じゃないけど、納得っつーか、328がスレ違いである、
ということを強く言いたいことは伝わってきたよ。
だから何なのかはよく分からん。
ということを強く言いたいことは伝わってきたよ。
だから何なのかはよく分からん。
普段からテストもデバッグもろくにしてないから
例外の導入によって潜在的欠陥の見える化が促進されると
今までごまかしてきたものが露呈するから困るって話でしょ。
例外の導入によって潜在的欠陥の見える化が促進されると
今までごまかしてきたものが露呈するから困るって話でしょ。
2-3人馬鹿が混じってきて堂々巡りしてるよね
無限ループって怖くね
無限ループって怖くね
例外使わないやつってよっぽど
手抜きプログラミングしてるんだろうな。
（エラーチェックしてないせいで）
例外ができたら落ちる！ 怖い！って
そんなのお前が手抜きしてるせいだろ。
手抜きプログラミングしてるんだろうな。
（エラーチェックしてないせいで）
例外ができたら落ちる！ 怖い！って
そんなのお前が手抜きしてるせいだろ。
と、すべての例外をthrowしてる奴が申しております。
「手抜き」の下手なプログラマ。
「キャッチボール」の下手なプログラマ。
プログラマ名乗るのやめちまえ
「キャッチボール」の下手なプログラマ。
プログラマ名乗るのやめちまえ
>>343
自分が言ったことは、自分で守れよ。
自分が言ったことは、自分で守れよ。
>>331
wwwwwwwwwwwww
wwwwwwwwwwwww
>>344
気持ち悪いから絡んで来るなよ。事務屋。
気持ち悪いから絡んで来るなよ。事務屋。
やっぱり例外をつかったほうがエラー処理はちゃんとしてるらしいな。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070925/282909/
> 最近はネットのコードでもエラー処理が充実しているのもあるが，やはりそれは例外。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070925/282909/
> 最近はネットのコードでもエラー処理が充実しているのもあるが，やはりそれは例外。
しかしこのスレほんと例外が理解できない馬鹿釣れまくりだなｗ
どんな良餌だよ
どんな良餌だよ
351 ：仕様書無しさん：2011/02/11(金) 17:25:16
例外を使うことが間違い。
>>348
掛詞かよｗ
掛詞かよｗ
353 ：仕様書無しさん：2011/02/11(金) 20:48:42
例外を正しく使わない（使えない）やつが釣れてるの間違いだろ
まぁ俺らが例外みたいなもんだし、でも誰もcatchされない
例外を上の方でキャッチしても、その上位の処理は、「何とかしろ」って言うだけだろが。
つまり、「何とかする」というメソッドを呼び出すだけだろ。
だったら、上までトラブルの詳細を報告する必要はねーんだよハゲ。
つまり、「何とかする」というメソッドを呼び出すだけだろ。
だったら、上までトラブルの詳細を報告する必要はねーんだよハゲ。
型を拡張して複数の解釈が出来るようにするのは間違いの元
例外は型が明確だから処理しやすい
内部で復旧できるものなら例外を発生させる必要はないけど
共通の復旧方法がきまってるなら、コピペしないでいいし、
無駄に判定する必要もなく共通処理にしやすい例外throwのほうがいい
馬鹿は投げ方捕まえ方がわからないから嫌いらしいけど
例外は型が明確だから処理しやすい
内部で復旧できるものなら例外を発生させる必要はないけど
共通の復旧方法がきまってるなら、コピペしないでいいし、
無駄に判定する必要もなく共通処理にしやすい例外throwのほうがいい
馬鹿は投げ方捕まえ方がわからないから嫌いらしいけど
なあ、もしかして、例外厨って論破される寸前？
だといいよなｗ
別スレッドで発生した例外って、そのスレッドで誰もキャッチしなかったら、
他のスレッドにも伝わってくるの？
もしもそうなら、かなり迷惑なんだけど。
誰もキャッチしないとプログラムが死ぬって事は、伝わってくるんだろうな・・・
他のスレッドにも伝わってくるの？
もしもそうなら、かなり迷惑なんだけど。
誰もキャッチしないとプログラムが死ぬって事は、伝わってくるんだろうな・・・
> 共通の復旧方法がきまってるなら
そんな簡単なものばかりやってるからw
そんな簡単なものばかりやってるからw
もしかして、スレッド間で同期取るために例外使うとかしてるの？
>>361
他のスレッドに伝わってくるのなら、そこで処理すれば終了しないし、
プログラムが死ぬのなら、他のスレッドに伝わってこないということ。
お前、例外の使い方分かってないだろ？
自分で言っていることが矛盾してるって気づいてないだろ？
他のスレッドに伝わってくるのなら、そこで処理すれば終了しないし、
プログラムが死ぬのなら、他のスレッドに伝わってこないということ。
お前、例外の使い方分かってないだろ？
自分で言っていることが矛盾してるって気づいてないだろ？
他のスレッドに伝わらないし、プログラムも死なない。
例外を問題が起きたときだけのものって考えてる人は少なくないと思う。
そう考えないと理解できないような頭の悪いレスとか結構あるし…。
そう考えないと理解できないような頭の悪いレスとか結構あるし…。
なにが言いたいのか、よーわからん
>>369
お前順番がおかしいぞ。
例外は、普通に送出していいんだよ。
それを考慮したら、想定内の例外で
考慮しなかったら、想定外の例外なんだよ。ｌ
想定内かどうかってのは、例外の送出側できまることではなく、
それを想定するかどうかってだけだろ。
お前順番がおかしいぞ。
例外は、普通に送出していいんだよ。
それを考慮したら、想定内の例外で
考慮しなかったら、想定外の例外なんだよ。ｌ
想定内かどうかってのは、例外の送出側できまることではなく、
それを想定するかどうかってだけだろ。
何を例外とするかなんて（正しく付けられた）
関数名見ればすぐに分かるけどね。
正しく付けられた名前ってのは処理の内容を
正しく表している名前という意味。
だからfooとかいうデタラメな関数名では、何を例外とするかはわからないけど、
saveとかいう関数名なら、saveできない状態はすべて例外にするとわかる
関数名見ればすぐに分かるけどね。
正しく付けられた名前ってのは処理の内容を
正しく表している名前という意味。
だからfooとかいうデタラメな関数名では、何を例外とするかはわからないけど、
saveとかいう関数名なら、saveできない状態はすべて例外にするとわかる
>>370
順番はいまどういうロジックを書いているかで決まるんだよ。
書いているのが汎用のライブラリなら、その考え方でいい。
ただし、大部分のプログラマはアプリケーションのロジックを書くのが仕事だから
そこを考慮しないで、普通に送出していいというから話がややこしくなる。
順番はいまどういうロジックを書いているかで決まるんだよ。
書いているのが汎用のライブラリなら、その考え方でいい。
ただし、大部分のプログラマはアプリケーションのロジックを書くのが仕事だから
そこを考慮しないで、普通に送出していいというから話がややこしくなる。
>>372
アプリケーションのロジックかどうかで
例外かどうかなんて決まらないよ。
何を例外とするかは、処理の内容で決まる。
処理の内容を表す正しい関数名をつけるなら
その関数名から、何を例外にするかなんてすぐに分かる。
何を例外とするかわからないなら、
処理の内容を正しく表した関数名を言ってみ。
答えてあげるから。
アプリケーションのロジックかどうかで
例外かどうかなんて決まらないよ。
何を例外とするかは、処理の内容で決まる。
処理の内容を表す正しい関数名をつけるなら
その関数名から、何を例外にするかなんてすぐに分かる。
何を例外とするかわからないなら、
処理の内容を正しく表した関数名を言ってみ。
答えてあげるから。
>>375
逃げるなよ
逃げるなよ
>>378
そうでもない。
そうでもない。
380 ：仕様書無しさん 冒険の書【Lv=23,xxxPT】 ：2011/02/12(土) 07:47:48
>>369
なにを想定してるかによる
回復処理まで含めてメソッドの担当というプログラム設計してるのなら
そりゃ例外を送出すべきでないが、そのメソッドの行う範囲でなければ例外
アプリケーションがどーとか、そういう事じゃなく、もっと部品として考えれ
たったこれだけの話なんだけど、本当にどうしようもない異常だけが例外だって
考えてる人にはそれすら理解できないようで、割と手に負えない
このあたりの溝は埋まらないものだと思って諦めるしかないのかもしれない
外部設計レベルの仕様だけみて、脳内プログラム設計をするお仕事な人は
行き当たりばったりなコードかくから、あっちゃこっちゃに重複コード埋め込みやがるからマジ簡便だわ
修正するときの影響範囲とかテストのコストとかも考えて欲しいわ
なにを想定してるかによる
回復処理まで含めてメソッドの担当というプログラム設計してるのなら
そりゃ例外を送出すべきでないが、そのメソッドの行う範囲でなければ例外
アプリケーションがどーとか、そういう事じゃなく、もっと部品として考えれ
たったこれだけの話なんだけど、本当にどうしようもない異常だけが例外だって
考えてる人にはそれすら理解できないようで、割と手に負えない
このあたりの溝は埋まらないものだと思って諦めるしかないのかもしれない
外部設計レベルの仕様だけみて、脳内プログラム設計をするお仕事な人は
行き当たりばったりなコードかくから、あっちゃこっちゃに重複コード埋め込みやがるからマジ簡便だわ
修正するときの影響範囲とかテストのコストとかも考えて欲しいわ
>>367
>例外を問題が起きたときだけのものって考えてる人は少なくないと思う。
そう考えてないから、おかしな使い方する奴を想定出来て、そいつらが
このスレで例外をアホみたいにプッシュしている事を茶化してるんだろｗ
>例外を問題が起きたときだけのものって考えてる人は少なくないと思う。
そう考えてないから、おかしな使い方する奴を想定出来て、そいつらが
このスレで例外をアホみたいにプッシュしている事を茶化してるんだろｗ
まともに使えないから火病ってるだけだよ
そうそう。例外なんてただの
strtol関数で失敗時には0を返します。
みたいな話でしかない。
失敗時に0とか-1とかを返したくなったら、
代わりに例外を返せばいいだけの話。
strtol関数で失敗時には0を返します。
みたいな話でしかない。
失敗時に0とか-1とかを返したくなったら、
代わりに例外を返せばいいだけの話。
関数のドキュメントを書くとして、
その戻り値に
成功時は～を返します。
失敗時は～を返します。
という文章を書きたくなったら
それは例外にするべきなんだよ。
戻り値は、成功時に返す値。
失敗時は、戻り値ではなく例外を使って返す。
すごく単純なルールだと思うんだがねぇ。
その戻り値に
成功時は～を返します。
失敗時は～を返します。
という文章を書きたくなったら
それは例外にするべきなんだよ。
戻り値は、成功時に返す値。
失敗時は、戻り値ではなく例外を使って返す。
すごく単純なルールだと思うんだがねぇ。
なんか、画期的な事言ってるみたいだけど、すぐに廃れるんだよね。
数年後には、例外は時代遅れとかホザいてるに違いない。
数年後には、例外は時代遅れとかホザいてるに違いない。
そんなお前の希望を言われてもなｗ
もし廃れるとしたら、他に優れた方法が見つかった時だよ。
現状、ほとんどの言語が例外をサポートしている。
今は正常な戻り値と異常な戻り値を分けて返す時代。
標準出力と、標準エラー出力も分かれてるよね。
もし廃れるとしたら、他に優れた方法が見つかった時だよ。
現状、ほとんどの言語が例外をサポートしている。
今は正常な戻り値と異常な戻り値を分けて返す時代。
標準出力と、標準エラー出力も分かれてるよね。
戻り値はbool型
すごく単純なルールだと思うんだがねぇ。
すごく単純なルールだと思うんだがねぇ。
えーと、例外ってもう何年続いてきた機能だっけ？
にわかプログラマなんで、詳しくは分らんけど、１５年くらいは経ってるかね？
にわかプログラマなんで、詳しくは分らんけど、１５年くらいは経ってるかね？
どうみても戻り値の劣化機能
明示的に書けないのが痛い
明示的に書けないのが痛い
正しく伝えたい相手に伝わる前に、おせっかいな処理が不適切に処理する事の出来る機能。それが、例外。
やっぱり例外は、戻り値とは後にできた、
戻り値よりも便利な機能なんだね。
戻り値よりも便利な機能なんだね。
>>389
書けると思うが？
try catchって知ってる？
>>390
> 正しく伝えたい相手に伝わる前に、おせっかいな処理が不適切に処理する事の出来る機能。それが、例外。
え？ ちゃんと一つ上の階層に伝わるじゃん。
エラーは必ず一つ上の階層に伝えるもんだよ。
お前は一体誰に伝えようとしてるんだ？
悪いプログラミングしてるな。
書けると思うが？
try catchって知ってる？
>>390
> 正しく伝えたい相手に伝わる前に、おせっかいな処理が不適切に処理する事の出来る機能。それが、例外。
え？ ちゃんと一つ上の階層に伝わるじゃん。
エラーは必ず一つ上の階層に伝えるもんだよ。
お前は一体誰に伝えようとしてるんだ？
悪いプログラミングしてるな。
まあ事実として、
・例外は戻り値のエラー返却方法より後にできた
・ほとんどの言語では例外がサポートされている。
・サポートされているだけではなく、標準ライブラリなどで多く使用されている。
これが事実だからね。
例外を否定することは、
多くの言語を否定するということ。
誰に対して偉そうな口を叩いているのか
自覚したほうがいいよ。
・例外は戻り値のエラー返却方法より後にできた
・ほとんどの言語では例外がサポートされている。
・サポートされているだけではなく、標準ライブラリなどで多く使用されている。
これが事実だからね。
例外を否定することは、
多くの言語を否定するということ。
誰に対して偉そうな口を叩いているのか
自覚したほうがいいよ。
一つ上の階層に伝えたいだけなのに、大げさな仕組み実装してバカじゃないの？
ちょっと前、例外厨は、もっと上の階層に伝える事を前提に話をしてたはず。
言うことがコロコロ変わってみっともなさすぎる。
ちょっと前、例外厨は、もっと上の階層に伝える事を前提に話をしてたはず。
言うことがコロコロ変わってみっともなさすぎる。
>>395
実装が大げさだから使うほうが楽できるんだよ。
しかも安全。
もっと上の階層に伝えるというのは
上の階層に伝えて、そこからさらに上の階層に伝えてと
関数の呼び出し階層を巻き戻すのが簡単という意味。
でもそれは、一つ上の階層に伝えるという事を繰り返して実装されてるだけで
一つずつの動作を見れば、必ず一つ上の階層に伝えてるだけ。
実装が大げさだから使うほうが楽できるんだよ。
しかも安全。
もっと上の階層に伝えるというのは
上の階層に伝えて、そこからさらに上の階層に伝えてと
関数の呼び出し階層を巻き戻すのが簡単という意味。
でもそれは、一つ上の階層に伝えるという事を繰り返して実装されてるだけで
一つずつの動作を見れば、必ず一つ上の階層に伝えてるだけ。
>>395
一つのエラーを伝えるためだけに、いくつもの橋渡しを、正常処理コードの中に埋め込んでる、戻り値厨の言うことじゃないなｗ
一つのエラーを伝えるためだけに、いくつもの橋渡しを、正常処理コードの中に埋め込んでる、戻り値厨の言うことじゃないなｗ
コンピュータを使っているのに
定型処理を自動化しないのは馬鹿。
定型処理を自動化しないのは馬鹿。
例えばの話、正常稼動中の人体というシステムに於いても、局所的には雑菌や
ウイルスとの間で細胞レベルの生き死にの事象が繰り広げられてるわな。
例外厨の言ってる事は、細胞が雑菌にやられて「ウギャー、死ぬるぅ～っ！」って
言ってるレベルのことを、人体そのものが「ウギャー、死ぬるぅ～っ！」っていう
事態にまで発展させ得るってことだ。
ちょっと化膿したけど、全体としては正常稼動の範囲内で収めるって事をよしと
しないパラノイア。 それが、例外厨。
ウイルスとの間で細胞レベルの生き死にの事象が繰り広げられてるわな。
例外厨の言ってる事は、細胞が雑菌にやられて「ウギャー、死ぬるぅ～っ！」って
言ってるレベルのことを、人体そのものが「ウギャー、死ぬるぅ～っ！」っていう
事態にまで発展させ得るってことだ。
ちょっと化膿したけど、全体としては正常稼動の範囲内で収めるって事をよしと
しないパラノイア。 それが、例外厨。
>>400
それ書くのに、お前の人生何分消費した？ｗ
それ書くのに、お前の人生何分消費した？ｗ
>>400
で、お前は、細胞が雑菌にやられて「ウギャー、死ぬるぅ～っ！」って、言ってるのを無視するんですねｗ
で、お前は、細胞が雑菌にやられて「ウギャー、死ぬるぅ～っ！」って、言ってるのを無視するんですねｗ
細胞が雑菌にやられてるのに、
それを認識できない状態ってのが
一番やばいだろ・・・
病気になっているのに、気づかないのは
もっと危険だって。
それを認識できない状態ってのが
一番やばいだろ・・・
病気になっているのに、気づかないのは
もっと危険だって。
・戻り値
明示的にエラー検出コードを書かないとエラー発生がわからず、
検出コードを書かない場合は、エラーを無視する方式
例え 痛みを感じず病気になってもわからない体
・例外
明示的にエラーを無視するコードを書かないと無視できず、
検出コードを書かなくてもエラーを検出できる方式。
例え 痛みを感じる体
明示的にエラー検出コードを書かないとエラー発生がわからず、
検出コードを書かない場合は、エラーを無視する方式
例え 痛みを感じず病気になってもわからない体
・例外
明示的にエラーを無視するコードを書かないと無視できず、
検出コードを書かなくてもエラーを検出できる方式。
例え 痛みを感じる体
>>406
今は、局所的な問題として処理できない問題の話をしている。
今は、局所的な問題として処理できない問題の話をしている。
>>407
(´・∀・｀)ﾍｰ ファイルが見つからなかったときの話が？
(´・∀・｀)ﾍｰ ファイルが見つからなかったときの話が？
ほとんどの人間は、水虫ぐらいでは「ウギャー、死ぬるぅ～っ！」とは言わない。
>>408
局所的な問題として処理できない問題の話をしてるんだよ。
ファイルが見つからなかった時というのは、
局所的な問題として処理できない問題か？
話を「局所的な問題として処理できない問題」に戻せよ。
局所的な問題として処理できない問題の話をしてるんだよ。
ファイルが見つからなかった時というのは、
局所的な問題として処理できない問題か？
話を「局所的な問題として処理できない問題」に戻せよ。
ハゲなら言うかもｗ
>>412
意味がわからん。
すべての問題が局所的に解決できるなら、
戻り値でエラーを返す必要だって無いだろ。
局所的に解決できない問題を
どうやって一つ上の階層に返すか、
それをどうやってチェックするか、
エラーを検出コードとエラーを無視させるコードの
どちらを明示的に書くようにしたほうが安全か
そういう話だよ。
意味がわからん。
すべての問題が局所的に解決できるなら、
戻り値でエラーを返す必要だって無いだろ。
局所的に解決できない問題を
どうやって一つ上の階層に返すか、
それをどうやってチェックするか、
エラーを検出コードとエラーを無視させるコードの
どちらを明示的に書くようにしたほうが安全か
そういう話だよ。
>>405
戻り値厨って、事あるごとに
明示的に書いたほうがいいと言うけど、
結局は、明示的に書くのが
エラー検出コードか、エラーを無視するコードかに変わるだけで、
片方のコードを書けば、片方のコードは要らなくなる
どちらにしろどちらか一つを明示的に書くことになるんだよね。
明示的に書くのはどっちのほうがいい？
そういう話。
戻り値厨って、事あるごとに
明示的に書いたほうがいいと言うけど、
結局は、明示的に書くのが
エラー検出コードか、エラーを無視するコードかに変わるだけで、
片方のコードを書けば、片方のコードは要らなくなる
どちらにしろどちらか一つを明示的に書くことになるんだよね。
明示的に書くのはどっちのほうがいい？
そういう話。
例外は、極力それを起こした処理内で落とし前つけるべき。
なのに、それが出来ない、というか例外を発生させにくいやり方を実装出来ない
アホが、他所様に尻ぬぐいを強要できる例外機構に甘えているだけだろ。
なのに、それが出来ない、というか例外を発生させにくいやり方を実装出来ない
アホが、他所様に尻ぬぐいを強要できる例外機構に甘えているだけだろ。
> 例外は、極力それを起こした処理内で落とし前つけるべき。
お前、前提間違ってるよ。
処理内で落とし前を付けられないから
それを例外という形で返すんだよ。
まったく、何もわかってないよこいつ。
そんな間違った前提で話しているやつの言う事、
誰が信用すると思う？
お前、前提間違ってるよ。
処理内で落とし前を付けられないから
それを例外という形で返すんだよ。
まったく、何もわかってないよこいつ。
そんな間違った前提で話しているやつの言う事、
誰が信用すると思う？
オマエが、他人の言葉尻を捉えて反論しているだけの人工無能だということは分かった。
さっきからずっとそんな感じ。
さっきからずっとそんな感じ。
ファイルが見つからないから例外投げます（ｷﾘｯ
なんか、根本的に間違ったことを言ってると、
あぁ、こいつは間違った知識を元に
発言をしているんだ。
なら何を言っても、間違いだなって
思っちゃうよね。
>>415の一行目を見た時にそんな気分になった。
あぁ、こいつは間違った知識を元に
発言をしているんだ。
なら何を言っても、間違いだなって
思っちゃうよね。
>>415の一行目を見た時にそんな気分になった。
>>414
どっちが良いかはケースバイケース
どっちが良いかはケースバイケース
>>420
じゃあ、どういうケースが、
「エラー検出コードを明示的に書かないと、エラーを無視してしまうコード」のほうが
「エラーを無視するコードを明示的に書かないと、エラーを検出してくれるコード」より
優れてるにあてはまるのさ。
じゃあ、どういうケースが、
「エラー検出コードを明示的に書かないと、エラーを無視してしまうコード」のほうが
「エラーを無視するコードを明示的に書かないと、エラーを検出してくれるコード」より
優れてるにあてはまるのさ。
そういうケースを思いつかないなら、
ケースバイケースなんて言わなければいいのに
ケースバイケースなんて言わなければいいのに
開発言語で既に用意している例外に飽き足らずに、俺様専用仕様の例外を
わざわざ投げるようにして、誰もそれをキャッチしなければプログラム死亡。
誰もその例外をキャッチしなかった時のリスクを、どうやって回避するの？
出来ないだろが。 キャッチする仕組みだけにはバグが生まれないのかよ。
わざわざ投げるようにして、誰もそれをキャッチしなければプログラム死亡。
誰もその例外をキャッチしなかった時のリスクを、どうやって回避するの？
出来ないだろが。 キャッチする仕組みだけにはバグが生まれないのかよ。
>>423
なんでそんなことを恐れているの？
エラーチェックをちゃんとしていれば落ちないよね。
バグがなければ落ちないよね。
いつもエラーチェックをやってないの？
いつもバグばかり書くような人なの？
落ちなければ、バグがあっても平気な人なの？
なんでそんなことを恐れているの？
エラーチェックをちゃんとしていれば落ちないよね。
バグがなければ落ちないよね。
いつもエラーチェックをやってないの？
いつもバグばかり書くような人なの？
落ちなければ、バグがあっても平気な人なの？
「ぼくのかんがえたさいきょうのれいがい」をキャッチしない方が悪いんですね、わかります。
当たり前だろ。
発生したエラーを処理しないほうが悪い。
お前はいつもエラー処理をしていないんだな。
発生したエラーを処理しないほうが悪い。
お前はいつもエラー処理をしていないんだな。
他人にキャッチを強要する前に、その必要性を無くす努力を自分の
処理内でしろよ無能、とか思っちゃいます＞＜
処理内でしろよ無能、とか思っちゃいます＞＜
>>423
誰も例外をキャッチしなかったなら、ちゃんとメッセージ吐いて知らせてくれる。
それから、バグとして処理すればいい。
戻り値の場合は、どこかで記入漏れがあったら、そのバグの特定が難しいから大変だけどな。
誰も例外をキャッチしなかったなら、ちゃんとメッセージ吐いて知らせてくれる。
それから、バグとして処理すればいい。
戻り値の場合は、どこかで記入漏れがあったら、そのバグの特定が難しいから大変だけどな。
>>427
そのケース、例外でいいけどな。
そのケース、例外でいいけどな。
>>427
可能なかぎり処理を継続すべきというのなら、
エラーを無視してはいけないだろ？
エラーチェックを省略したときに
無視すると、処理は継続できなくなる。
落ちなくても正しく動いていないのなら継続できてないのと同じこと。
それこそ、何も書かなくてもエラーを検出してくれるコードのほうが
いいじゃないか。仕様漏れであっても明示的にエラーチェックを書かなくても
例外ならすべてのエラーを検出できるのだから。
可能なかぎり処理を継続すべきというのなら、
エラーを無視してはいけないだろ？
エラーチェックを省略したときに
無視すると、処理は継続できなくなる。
落ちなくても正しく動いていないのなら継続できてないのと同じこと。
それこそ、何も書かなくてもエラーを検出してくれるコードのほうが
いいじゃないか。仕様漏れであっても明示的にエラーチェックを書かなくても
例外ならすべてのエラーを検出できるのだから。
自分の処理内で解決できない事が、なんで他の処理だと解決できると
期待できるんだろうかｗ
期待できるんだろうかｗ
他の処理は、例外を起こした処理の内部事情が分からんはずなのに。
そもそも、「ぼくのかんがえたさいきょうのれいがい」には、詳しい事情が含まれてるんだろ？
だったら、必要に応じてその詳細を、「穏便な形」で参照できる様にしておけば
いいだけじゃないのか？ 通常の処理を実行させつつ。 他の処理が。
なんで、例外という通常の処理から外れる事を強要する形でしか詳細を参照させないの？
そもそも、「ぼくのかんがえたさいきょうのれいがい」には、詳しい事情が含まれてるんだろ？
だったら、必要に応じてその詳細を、「穏便な形」で参照できる様にしておけば
いいだけじゃないのか？ 通常の処理を実行させつつ。 他の処理が。
なんで、例外という通常の処理から外れる事を強要する形でしか詳細を参照させないの？
> 他の処理は、例外を起こした処理の内部事情が分からんはずなのに。
あほか。関数内部の実装にこだわってどうする。
関数内部の事情はわからんように作るものだ。
関数内部を関数外部にばらしてはいけない。
関数内部で処理できる問題は関数内部で処理して
（つまりリソース解放などの異常状態修復処理だ）
それを処理した後、エラーが起きたという情報だけを返すんだよ。
例外＝ただのエラー情報だ。
お前はプログラミングの基礎すらわかってない。
あほか。関数内部の実装にこだわってどうする。
関数内部の事情はわからんように作るものだ。
関数内部を関数外部にばらしてはいけない。
関数内部で処理できる問題は関数内部で処理して
（つまりリソース解放などの異常状態修復処理だ）
それを処理した後、エラーが起きたという情報だけを返すんだよ。
例外＝ただのエラー情報だ。
お前はプログラミングの基礎すらわかってない。
>あほか。関数内部の実装にこだわってどうする。
そういう事言ってんじゃないっての。
例外を受け取らされた方は、当然詳細な情報をもとに対処したいはずで、
そのネタ元が、「ぼくのかんがえたさいきょうのれいがい」中の情報なら、
その情報を作った側、即ち例外を投げた側が、その情報を元に問題を解決
できるはずだろうが。
他人に尻ぬぐいさせる前に、テメェが落とし前つけろって言ってるだけなんだけど。
そういう事言ってんじゃないっての。
例外を受け取らされた方は、当然詳細な情報をもとに対処したいはずで、
そのネタ元が、「ぼくのかんがえたさいきょうのれいがい」中の情報なら、
その情報を作った側、即ち例外を投げた側が、その情報を元に問題を解決
できるはずだろうが。
他人に尻ぬぐいさせる前に、テメェが落とし前つけろって言ってるだけなんだけど。
>>437
お前、エラー処理したこと無いだろ？
お前、エラー処理したこと無いだろ？
>>437
> で、随所で全例外を無視するような謎コードが出来上がるってわけだ。
前提を忘れてないか？
可能なかぎり動き続けるように作る必要がある例をだしたから
そのコードで間違いないだろ。
それともお前は、全例外・・・戻り値でも同じだから言い直す、
全部のエラーを無視せずに可能なかぎり動く動くソフトを作れるのか？
> で、随所で全例外を無視するような謎コードが出来上がるってわけだ。
前提を忘れてないか？
可能なかぎり動き続けるように作る必要がある例をだしたから
そのコードで間違いないだろ。
それともお前は、全例外・・・戻り値でも同じだから言い直す、
全部のエラーを無視せずに可能なかぎり動く動くソフトを作れるのか？
>>438
お前、例外の中にどんな情報が入っていると思ってるのか？
なんかさぁ。例外の中にファイルハンドルとか格納されていると思ってね？
呼び出し元で、関数内部でオープンしたファイルを呼び出し元で閉じるとか思ってね？
そんな事するわけ無いだろ。あたりまえだよ。
例外の中に含まれるのは、発生したエラーの情報であって内部情報は一切含まれない。
内部の状態を回復されるのは、例外を投げる側の責任で、
エラーが起きたという情報を伝えるだけ。
> 他人に尻ぬぐいさせる前に、テメェが落とし前つけろって言ってるだけなんだけど。
お前の言い方をするとな、落とし前は、テメェで付けて、
親分（呼び出し元関数）に落とし前（例外）つけましたって報告するだけ
お前、例外の中にどんな情報が入っていると思ってるのか？
なんかさぁ。例外の中にファイルハンドルとか格納されていると思ってね？
呼び出し元で、関数内部でオープンしたファイルを呼び出し元で閉じるとか思ってね？
そんな事するわけ無いだろ。あたりまえだよ。
例外の中に含まれるのは、発生したエラーの情報であって内部情報は一切含まれない。
内部の状態を回復されるのは、例外を投げる側の責任で、
エラーが起きたという情報を伝えるだけ。
> 他人に尻ぬぐいさせる前に、テメェが落とし前つけろって言ってるだけなんだけど。
お前の言い方をするとな、落とし前は、テメェで付けて、
親分（呼び出し元関数）に落とし前（例外）つけましたって報告するだけ
どの言語も例外備えてるというのに、
例外を分かってないやつって
本当にいるんだなｗ
C言語しか出来ない人？
例外を分かってないやつって
本当にいるんだなｗ
C言語しか出来ない人？
>>444
どうやら、例外に内部情報を格納するから
呼び出し元で解決するんだと考えていたらしいよｗ
内部情報を解決するのは、内部事情を知り尽くしている内部。
例外はただの報告にすぎないというのを
理解してない。
例外をオブジェクトだと思っているかね。
まあ、オブジェクトもわかってないのだろうけど。
どうやら、例外に内部情報を格納するから
呼び出し元で解決するんだと考えていたらしいよｗ
内部情報を解決するのは、内部事情を知り尽くしている内部。
例外はただの報告にすぎないというのを
理解してない。
例外をオブジェクトだと思っているかね。
まあ、オブジェクトもわかってないのだろうけど。
>お前の言い方をするとな、落とし前は、テメェで付けて、
>親分（呼び出し元関数）に落とし前（例外）つけましたって報告するだけ
じゃあ、戻り値でもいいじゃんｗ 詳細情報は、そいつのプロパティにでも持たせとけよｗｗｗ
>親分（呼び出し元関数）に落とし前（例外）つけましたって報告するだけ
じゃあ、戻り値でもいいじゃんｗ 詳細情報は、そいつのプロパティにでも持たせとけよｗｗｗ
>>444
自分の外部に関するエラー処理は、自分じゃ出来ないでしょ。
自分の外部に関するエラー処理は、自分じゃ出来ないでしょ。
>>446
一つの理由としては、正常な値と異常な値を
同じやり方で返すというのが問題。
特に型あり言語では、戻り値の型をintにすると、
詳細情報を別の型として返すことができない。
戻り値の型ごとに違うやり方で詳細情報を
取得しないといけない。
他にも理由は沢山あるが、ようするに不便なんだよ。
一つの理由としては、正常な値と異常な値を
同じやり方で返すというのが問題。
特に型あり言語では、戻り値の型をintにすると、
詳細情報を別の型として返すことができない。
戻り値の型ごとに違うやり方で詳細情報を
取得しないといけない。
他にも理由は沢山あるが、ようするに不便なんだよ。
>詳細情報を別の型として返すことができない。
なにいってんの。 戻り値そのものは、正常な値とそれ以外が分かれば
いいのであって、詳細は別のプロパティを参照させればいいだけだろ。
その処理が失敗したら、例外発生で別ルートに強制的に飛ばされるより
かは、次善の策を講じて次の処理を継続させたいけどね。
それとも、例外処理した後で次のコードに戻らせるのか？ その方が分
かり辛いわ。
なにいってんの。 戻り値そのものは、正常な値とそれ以外が分かれば
いいのであって、詳細は別のプロパティを参照させればいいだけだろ。
その処理が失敗したら、例外発生で別ルートに強制的に飛ばされるより
かは、次善の策を講じて次の処理を継続させたいけどね。
それとも、例外処理した後で次のコードに戻らせるのか？ その方が分
かり辛いわ。
ある処理が失敗したら例外が発生して、その時の例外処理はこの
例外クラスでキャッチして・・・って
扱う対象が投げるかも知れない全ての種類の例外とその発生タイミ
ングを把握してないといけないのかよ。
例外クラスでキャッチして・・・って
扱う対象が投げるかも知れない全ての種類の例外とその発生タイミ
ングを把握してないといけないのかよ。
だから、エラーだから落ちてもいいプログラムは、例外が楽で。
救急でないエラーは落ちないで正常に動く必要があるプログラムは、例外はめんどい。
それだけの話しさ。
救急でないエラーは落ちないで正常に動く必要があるプログラムは、例外はめんどい。
それだけの話しさ。
>>449
> いいのであって、詳細は別のプロパティを参照させればいいだけだろ。
じゃあその別のプロパティとは？
そのルールが決まってない。
あるものはerrnoかもしれないし、
別のライブラリは。ErrorNumberかもしれない。
ライブラリごとに違っていれば、その詳細情報を
取得するコードも複雑になる。
統一したやり方ができないってのも問題の一つ。
>>449
> その処理が失敗したら、例外発生で別ルートに強制的に飛ばされるより
> かは、次善の策を講じて次の処理を継続させたいけどね。
別ルートに飛ばしたくないのなら、飛ばさないコードを書けばいいだけ。
関数をtryで囲むだけだから、見ればすぐに分かる。
> いいのであって、詳細は別のプロパティを参照させればいいだけだろ。
じゃあその別のプロパティとは？
そのルールが決まってない。
あるものはerrnoかもしれないし、
別のライブラリは。ErrorNumberかもしれない。
ライブラリごとに違っていれば、その詳細情報を
取得するコードも複雑になる。
統一したやり方ができないってのも問題の一つ。
>>449
> その処理が失敗したら、例外発生で別ルートに強制的に飛ばされるより
> かは、次善の策を講じて次の処理を継続させたいけどね。
別ルートに飛ばしたくないのなら、飛ばさないコードを書けばいいだけ。
関数をtryで囲むだけだから、見ればすぐに分かる。
×救急
○緊急
○緊急
>>453
> だから、エラーだから落ちてもいいプログラムは、例外が楽で。
エラー処理をすれば落ちない。
落ちるときはエラー処理をしていなかったとき。
落ちることは許されないから、
エラー処理をやらなかったとき落ちるほうが、
覚悟をもってプログラミングしている。
俺らは絶対に落とさないために
エラー処理を省くということはしないという覚悟が出来てる。
> 救急でないエラーは落ちないで正常に動く必要があるプログラム
緊急でないエラーは落ちないで正常に動くと
明示的に書くことはすごく重要。
明示的にエラーを無視するのか、単に忘れているのか
その違いがわからないほうが危険。
> だから、エラーだから落ちてもいいプログラムは、例外が楽で。
エラー処理をすれば落ちない。
落ちるときはエラー処理をしていなかったとき。
落ちることは許されないから、
エラー処理をやらなかったとき落ちるほうが、
覚悟をもってプログラミングしている。
俺らは絶対に落とさないために
エラー処理を省くということはしないという覚悟が出来てる。
> 救急でないエラーは落ちないで正常に動く必要があるプログラム
緊急でないエラーは落ちないで正常に動くと
明示的に書くことはすごく重要。
明示的にエラーを無視するのか、単に忘れているのか
その違いがわからないほうが危険。
落ちることを恐れているやつは、
自分のコードが落ちる可能性があると自覚しているから。
いつもエラーチェックをサボっているから、
エラーチェックをサボった場合は落ちるという
仕組みを採用できない。
自分のコードが落ちる可能性があると自覚しているから。
いつもエラーチェックをサボっているから、
エラーチェックをサボった場合は落ちるという
仕組みを採用できない。
もうそろそろセミナー技術に踊らされる段階は卒業してもいいと思う
まさか例外のことじゃないよな？
こんどはセミナー技術か（笑）
お前に取っては、セミナーで習うようなものなのかよ。
ほとんどの言語で使われている例外を
使えないやつはプログラマじゃないぞ。
こんどはセミナー技術か（笑）
お前に取っては、セミナーで習うようなものなのかよ。
ほとんどの言語で使われている例外を
使えないやつはプログラマじゃないぞ。
ほとんどの言語って・・・
OOPLだけだろ。
OOPLだけだろ。
ほとんどの言語がOOPLなんだから
ほとんどの言語で問題ないだろ？
それと関数型言語でも例外は使われてる。
ほとんどの言語で問題ないだろ？
それと関数型言語でも例外は使われてる。
プログラマじゃない、は言い過ぎだろ
１つの関数なりメソッド内に、複数の try - catch のカタマリが存在するソースコードっすかｗ
素敵っすねｗｗｗ キレイっすねｗｗｗ
素敵っすねｗｗｗ キレイっすねｗｗｗ
>>462
ifとかforとか代入とか、どの言語にも共通して存在する
基本的な命令ってあるのよ。
今は例外も、その共通に存在する機能に含まれている。
それが使えないやつはプログラマじゃないといっても
言い過ぎじゃないよ。
>>463
じゃあ、わけろ
ifとかforとか代入とか、どの言語にも共通して存在する
基本的な命令ってあるのよ。
今は例外も、その共通に存在する機能に含まれている。
それが使えないやつはプログラマじゃないといっても
言い過ぎじゃないよ。
>>463
じゃあ、わけろ
>>459
この業界はいつもそうだけど新しい技術の良し悪しをまったく判断せずに
とにかく何でも取り込んでしまう傾向がある
まったく数字を出せない技術なのにただ新しいだけというだけで取り込んでしまう
クラウドしかり、オブジェクト指向しかり、スクリプト言語しかり
できることはまったくいっしょのくせして折角勉強した僕の技術が無駄になっちゃうなんて嫌だよ的な
意地もあるもんだからみんなして一生懸命戦っちゃう
この業界で一番大事なことはこういうくだらない技術に流されずに
ちゃんと比較、検討することだ
説明のできないメリットを認めないことも大事だ
この業界はいつもそうだけど新しい技術の良し悪しをまったく判断せずに
とにかく何でも取り込んでしまう傾向がある
まったく数字を出せない技術なのにただ新しいだけというだけで取り込んでしまう
クラウドしかり、オブジェクト指向しかり、スクリプト言語しかり
できることはまったくいっしょのくせして折角勉強した僕の技術が無駄になっちゃうなんて嫌だよ的な
意地もあるもんだからみんなして一生懸命戦っちゃう
この業界で一番大事なことはこういうくだらない技術に流されずに
ちゃんと比較、検討することだ
説明のできないメリットを認めないことも大事だ
ま、オブジェクト指向とか
例外に関しては、新しい技術ではなく、
すでに十数年、数十年も研究と実績を
積んでいるわけだから
すでに流行りの技術を通り越して
常識になってるんだけどね。
例外に関しては、新しい技術ではなく、
すでに十数年、数十年も研究と実績を
積んでいるわけだから
すでに流行りの技術を通り越して
常識になってるんだけどね。
こういう掲示板でもなきゃ誰も新しく出る技術にＮｏといわないよね
少なくともメリットとデメリットぐらいは挙げてもいいもんだと思うが
それも出ないまま次の言語にはなんの選別もされずにただ取り込まれていくだけ
少なくともメリットとデメリットぐらいは挙げてもいいもんだと思うが
それも出ないまま次の言語にはなんの選別もされずにただ取り込まれていくだけ
>>463
別にtryは一つだけでもいいっすよ？
別にtryは一つだけでもいいっすよ？
このスレは例外のスレで、
新しく出る技術の話なんかしてないぞ。
新しく出る技術の話なんかしてないぞ。
27年も続いてる機能に何を今さら。
俺は先週知ったんだから
新しい技術だ。
新しい技術だ。
>>466
積んでいないと思うね
せめて、反対意見をかき集めてきてみろよ
不思議とこの業界は誰もなんにもいわないんだ
まあ、理由はわからないでもないけどね
プログラムなんて組んでる奴ってのは頭悪い（社会的意味で）んだよ
だから大して研究もされない、しても金にならない
今の日本みたいにコストが上がればすぐに中国に仕事を渡すし
いままで一定レベルの技術者が長くやった歴史がおそらくない
つまり、ＰＧやってる奴に職人も歴史もないんであって
みんな馬鹿ばっかりだから（もちろん俺も含めて）誰も疑問を持たない
プログラム以外のことになにか打ち込んだことあるか？
他の技術、例えば料理とか歴史の長いものだ
そういう技術と比較するとプログラムは驚くほど底が浅い
いいプログラムの定義も明文化されてない
このスレにもいたがコードが短ければ短いほど「いい」と思ってる奴がいる
明らかにアフォだが、それをアフォだと明確に説明できる文章や定義もまだ未開拓過ぎて存在しない
積んでいないと思うね
せめて、反対意見をかき集めてきてみろよ
不思議とこの業界は誰もなんにもいわないんだ
まあ、理由はわからないでもないけどね
プログラムなんて組んでる奴ってのは頭悪い（社会的意味で）んだよ
だから大して研究もされない、しても金にならない
今の日本みたいにコストが上がればすぐに中国に仕事を渡すし
いままで一定レベルの技術者が長くやった歴史がおそらくない
つまり、ＰＧやってる奴に職人も歴史もないんであって
みんな馬鹿ばっかりだから（もちろん俺も含めて）誰も疑問を持たない
プログラム以外のことになにか打ち込んだことあるか？
他の技術、例えば料理とか歴史の長いものだ
そういう技術と比較するとプログラムは驚くほど底が浅い
いいプログラムの定義も明文化されてない
このスレにもいたがコードが短ければ短いほど「いい」と思ってる奴がいる
明らかにアフォだが、それをアフォだと明確に説明できる文章や定義もまだ未開拓過ぎて存在しない
>>472
いや、お前がなんといおうが、27年前からあって
ほぼすべての言語で採用されている機能ってのは
事実だから。
その事実と、誰もがそれを認めて反論してない現状。
それに対して２ちゃんねるだけでごちゃごちゃいってるお前。
信用に価するのはどっち？
いや、お前がなんといおうが、27年前からあって
ほぼすべての言語で採用されている機能ってのは
事実だから。
その事実と、誰もがそれを認めて反論してない現状。
それに対して２ちゃんねるだけでごちゃごちゃいってるお前。
信用に価するのはどっち？
例外に関していうと
機能がごちゃごちゃと複雑でぶっちゃけこの機能つけた奴の狙いが
さっぱりわからないって表現が一番マッチするのだけど
あえて表現するとしたら
例外を使ったコードの明示的な表現力の意味として
例外を使ったコードの品質は悪い
こういう視点を数値化するほど歴史が深いならお前等を納得させることもできただろうな
だが、そんなものは今はないんだ
それは歴史が浅すぎて誰も「いい」コードの基準を明確に表現できていないことが原因だと思うんだよね
機能がごちゃごちゃと複雑でぶっちゃけこの機能つけた奴の狙いが
さっぱりわからないって表現が一番マッチするのだけど
あえて表現するとしたら
例外を使ったコードの明示的な表現力の意味として
例外を使ったコードの品質は悪い
こういう視点を数値化するほど歴史が深いならお前等を納得させることもできただろうな
だが、そんなものは今はないんだ
それは歴史が浅すぎて誰も「いい」コードの基準を明確に表現できていないことが原因だと思うんだよね
>>475
全部お前の思い込みだろ？
たとえば、例外を使うと
エラーチェックをしないと落ちるから、
絶対にエラーチェックを省かないように
品質の高いコードができる。
エラーチェックをしないと落ちる。怖い。心配だ。
いつもエラーチェックしてないのがバレる。
こういう考えのやつに高井あ品質のコードが作れるわけがない。
全部お前の思い込みだろ？
たとえば、例外を使うと
エラーチェックをしないと落ちるから、
絶対にエラーチェックを省かないように
品質の高いコードができる。
エラーチェックをしないと落ちる。怖い。心配だ。
いつもエラーチェックしてないのがバレる。
こういう考えのやつに高井あ品質のコードが作れるわけがない。
>>473
お前のは思考停止だろ
いいも悪いも説明できない
ただ、長いものにまかれてそれが正しいという主張を繰り返してるだけ
仮に俺と結論がまったく同じになったとしてもお前といっしょにするなというクズな脳みその持ち主
お前のは思考停止だろ
いいも悪いも説明できない
ただ、長いものにまかれてそれが正しいという主張を繰り返してるだけ
仮に俺と結論がまったく同じになったとしてもお前といっしょにするなというクズな脳みその持ち主
>>478
例外のが優れていることはさんざんこのスレで証明済みだろ。
戻り値の方に、正常値と異常値を混ぜなくてすむ。
例外を使うと、エラーチェックをサボると落ちるから、サボらなくなる。
エラー状態を無視するには、明示的にコードを書かないといかず
明示的にコードを書かないならば、エラーチェックが標準で行われる。
それに対して、反論が出たか？でないだろ。
例外のが優れていることはさんざんこのスレで証明済みだろ。
戻り値の方に、正常値と異常値を混ぜなくてすむ。
例外を使うと、エラーチェックをサボると落ちるから、サボらなくなる。
エラー状態を無視するには、明示的にコードを書かないといかず
明示的にコードを書かないならば、エラーチェックが標準で行われる。
それに対して、反論が出たか？でないだろ。
>>481
> と、例外をすべてthrowしてる奴が申しております
日本語としておかしいぞ。 CPU例外の話をしてないか？
例外はthrowするものなんだが。
throwしない例外なんてありえないぞ。
お前が言いたいのはCPU例外が発生したときに
それをthrowするという意味だろ。
> と、例外をすべてthrowしてる奴が申しております
日本語としておかしいぞ。 CPU例外の話をしてないか？
例外はthrowするものなんだが。
throwしない例外なんてありえないぞ。
お前が言いたいのはCPU例外が発生したときに
それをthrowするという意味だろ。
>>481
いや、例外は普通throwする物だろ・・・
いや、例外は普通throwする物だろ・・・
丸投げもできるから別に品質が高いわけじゃないよな
ファイル読み込みのミスで例外がおきてくれるとかも品質が高くなってるわけじゃないし
新しい技術に疑問を投げる人が居ないから続いてるって言うけど、
それだったら、ハンガリアン記法はまだ廃れてないだろうな。
それだったら、ハンガリアン記法はまだ廃れてないだろうな。
例外を理解してなくて、CPU例外のことしかしらんやつは
気を抜くとすぐにCPU例外の話をしてしまうなｗ
気を抜くとすぐにCPU例外の話をしてしまうなｗ
>>485
品質を高くするかどうかってのは、例外をおこす側の話じゃなくて、
それをトラップする側の話だろ。
エラーチェックをちゃんとすれば、品質は高くなる。
例外だとエラーチェックをしなければ落ちるから
自然とエラーチェックをするようになる。
品質を高くするかどうかってのは、例外をおこす側の話じゃなくて、
それをトラップする側の話だろ。
エラーチェックをちゃんとすれば、品質は高くなる。
例外だとエラーチェックをしなければ落ちるから
自然とエラーチェックをするようになる。
>>488
いや、別にハンガリアン記法が良いとか、そういう話ではなく・・・
いや、別にハンガリアン記法が良いとか、そういう話ではなく・・・
>>491
ハンガリアンが糞だと
ハンガリアンが糞だと
ジャンガリアンならうちで走ってる
>>493
いや、別にハンガリアン記法を否定したい訳でもなく・・・（実際アプリケーションハンガリアンは良いと思ってる）
いや、別にハンガリアン記法を否定したい訳でもなく・・・（実際アプリケーションハンガリアンは良いと思ってる）
>>495
ハンガリアンは駄目だね
ハンガリアンは駄目だね
最近は戻り値でエラーを返す方法が廃れてしまったよね。
ハンガリアンと同じで。
どの言語も例外ばっかり使う。
ハンガリアンと同じで。
どの言語も例外ばっかり使う。
ハンガリアンバンザイ！
やっぱり例外をつかったほうがエラー処理はちゃんとしてるらしいな。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070925/282909/
> 最近はネットのコードでもエラー処理が充実しているのもあるが，やはりそれは例外。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070925/282909/
> 最近はネットのコードでもエラー処理が充実しているのもあるが，やはりそれは例外。
良くないやり方ってのは、絶対批判されるし、
すぐに廃れるものさ。
例外はそれに当てはまらないから、廃れるどころか
次々に言語仕様に追加されたり、新しい言語でサポートされてる。
すぐに廃れるものさ。
例外はそれに当てはまらないから、廃れるどころか
次々に言語仕様に追加されたり、新しい言語でサポートされてる。
わからないなら、黙ってろよｗ
D言語だと、scope文が追加されたり、関数の属性にnothrowを付けれたり・・・
え？そんな言語知らないって？
え？そんな言語知らないって？
悪貨は良貨を駆逐するという言葉はなんでできたのだろう・・・
>>508
悪貨を批判するためにできたんじゃないのか？ｗ
悪貨を批判するためにできたんじゃないのか？ｗ
今日の戻り値厨は防戦一方だなｗ
人が多いときはいつもこんな感じだけどな。
ほとんどの言語で例外がサポートされても、戻り値は駆逐されていない
例外厨は現実を見ようよｗ
例外厨は現実を見ようよｗ
>>512
いや、別に正常処理の時の話はしてないし。
いや、別に正常処理の時の話はしてないし。
>>512
だからそれは思考停止してるから考えたことないんだろ？
だからそれは思考停止してるから考えたことないんだろ？
すぐ上の階層に例外投げたいだけなのになんでこんなゴテゴテした仕組みを作ったの？
馬鹿なの？死ぬの？
馬鹿なの？死ぬの？
>>515
仕組み自体は随分と単純なんだけどね。
仕組み自体は随分と単純なんだけどね。
> すぐ上の階層に例外投げたいだけなのになんでこんなゴテゴテした仕組みを作ったの？
戻り値の型にエラー情報を問題なく紛れ込ませるのが苦痛だから
戻り値の型にエラー情報を問題なく紛れ込ませるのが苦痛だから
まぁ言語のマニュアルに「例外の使い方のガイドライン」なんてのが
出て来る辺り、世間では「例外とは何であるか」について
まだまだコンセンサスが取れてないことがうかがえる。
多分あともう1回ぐらいは世代が入れ代わる期間が要るんじゃないかなー
出て来る辺り、世間では「例外とは何であるか」について
まだまだコンセンサスが取れてないことがうかがえる。
多分あともう1回ぐらいは世代が入れ代わる期間が要るんじゃないかなー
戻り値厨はもみ消した例外によるバグが起きて
画面を見ながら「なんで動いてないんだろう」って悩みながら1日を無駄に過ごす人種
画面を見ながら「なんで動いてないんだろう」って悩みながら1日を無駄に過ごす人種
javaでキャッチしないとエラーが出る例外をどうしてくれようか考える毎日
例外を発生する処理を呼び出しているのに、
その例外が発生した場合の動作を考慮しない奴が、
「例外を発生した処理のせいだー俺は悪くないんだー」って喚いてるだけだよ
例外の発生する処理を呼び出す場合、その例外についてどう振舞うかを決めるのは呼び出し側なんだから
こんなバグ実装をしてる馬鹿なんて、クラスリファレンスだとかドキュメント類の、
メソッドの仕様見ないでコピペだけで実装してる馬鹿くらいでしょ？(笑)
その例外が発生した場合の動作を考慮しない奴が、
「例外を発生した処理のせいだー俺は悪くないんだー」って喚いてるだけだよ
例外の発生する処理を呼び出す場合、その例外についてどう振舞うかを決めるのは呼び出し側なんだから
こんなバグ実装をしてる馬鹿なんて、クラスリファレンスだとかドキュメント類の、
メソッドの仕様見ないでコピペだけで実装してる馬鹿くらいでしょ？(笑)
検査例外のある言語で throws Exception って書かれてるととりあえず壁パン代行に電話したくなる
理解してない奴がコンパイルエラーを避けるためだけにこんなことをやるんだよな
理解してない奴がコンパイルエラーを避けるためだけにこんなことをやるんだよな
>>521
正直、わからないことがあったら見ればいい程度にしてくれないと効率悪くて・・・
正直、わからないことがあったら見ればいい程度にしてくれないと効率悪くて・・・
戻り値でエラーを返すと言ってる人、
エラーが返ってきたとき、どんなすごいことやってるんだ？
俺はエラーが返ってきた後、ログ吐くか、
再試行するか、終了するぐらいしか思いつかないんだが。
エラーが返ってきたとき、どんなすごいことやってるんだ？
俺はエラーが返ってきた後、ログ吐くか、
再試行するか、終了するぐらいしか思いつかないんだが。
>>523
どんな例外が返ってくるかわかってないんなら見ろよ
その無知で正常系しか考えてないような実装がテストやら運用やら
周りの効率を落とす原因だっつーの
実相寺にどうしてもドキュメント確認するのが面倒なら事前に勉強して覚えとけｗ
どんな例外が返ってくるかわかってないんなら見ろよ
その無知で正常系しか考えてないような実装がテストやら運用やら
周りの効率を落とす原因だっつーの
実相寺にどうしてもドキュメント確認するのが面倒なら事前に勉強して覚えとけｗ
なんでそんなにどんな例外が返ってくるか気にしてるの？
たとえばファイルをオープンできなかったとき
その出来ない原因を気にしたりしないでしょ？
たとえばファイルをオープンできなかったとき
その出来ない原因を気にしたりしないでしょ？
ファイルがあるという前提だからないことは想定しないでいいとか
そういうアホな理由でエラーチェックをしないでいいと決め付けて
苦手なタイピング量を少しでも減らせるように努力()したいんだろ
だから検査例外とかでコンパイル通らなかったりして、例外を投げる側が悪いってﾌｧﾋﾞｮる
ゴミ臭い半島や中華と同じ発想だわ
そういうアホな理由でエラーチェックをしないでいいと決め付けて
苦手なタイピング量を少しでも減らせるように努力()したいんだろ
だから検査例外とかでコンパイル通らなかったりして、例外を投げる側が悪いってﾌｧﾋﾞｮる
ゴミ臭い半島や中華と同じ発想だわ
>>524
別に例外でやったっていいけども。
再試行や復帰に準備が必要な場合、ややこしくなってくよ。
組み込みだとこんなのはわりとある。
ROMの設定ファイルアクセスに失敗
さらに4回リトライに失敗
ROMイメージを別経路で書き込む
それが失敗したらハード異常
それが成功したら再度5回までリトライ
全部失敗したらハード異常
ハード異常の場合、ハード異常アラートをONにして
プログラムに埋め込みのデフォルト設定をロード。
ロードされた設定で以降の処理を続行。
別に例外でやったっていいけども。
再試行や復帰に準備が必要な場合、ややこしくなってくよ。
組み込みだとこんなのはわりとある。
ROMの設定ファイルアクセスに失敗
さらに4回リトライに失敗
ROMイメージを別経路で書き込む
それが失敗したらハード異常
それが成功したら再度5回までリトライ
全部失敗したらハード異常
ハード異常の場合、ハード異常アラートをONにして
プログラムに埋め込みのデフォルト設定をロード。
ロードされた設定で以降の処理を続行。
>>529
逆じゃね？
ドキュメント見れば十分なのに、
ヘッダ見ないといけないだろ？
つーか、ヘッダにどういうときに
エラー定数XXXが帰ります。
こういう場合はＯＯＯです。
なんて書いてあるのかよ。
逆じゃね？
ドキュメント見れば十分なのに、
ヘッダ見ないといけないだろ？
つーか、ヘッダにどういうときに
エラー定数XXXが帰ります。
こういう場合はＯＯＯです。
なんて書いてあるのかよ。
ヘッダってことはC言語なんだろうけど
関数の戻り値の型がintの場合、
どんなエラーが起きたかはドキュメントみないと
わからないよ。
戻り値の型がエラー型ならいいけども。
関数の戻り値の型がintの場合、
どんなエラーが起きたかはドキュメントみないと
わからないよ。
戻り値の型がエラー型ならいいけども。
引数と戻り値しか考慮できない馬鹿にはこのあたりが限度なんだからもう許してやれよ
周りがみんなそんな感じの糞職場で一生を終えて、外に出てこないでくれればそれでいい
周りがみんなそんな感じの糞職場で一生を終えて、外に出てこないでくれればそれでいい
C言語って関数の戻り値に
列挙型って指定できたっけ？
列挙型って指定できたっけ？
>>529
処理ができなかった場合に、そのクラス、そのメソッドは何を返すかをヘッダー見ただけでわかるのか？
結局異常系は全く考慮できない馬鹿の典型じゃねーか
お前みたいな馬鹿のせいで、他のクラスが正常に動かなくったりして
全員が無駄な残業を強いられるんだっつーの
処理ができなかった場合に、そのクラス、そのメソッドは何を返すかをヘッダー見ただけでわかるのか？
結局異常系は全く考慮できない馬鹿の典型じゃねーか
お前みたいな馬鹿のせいで、他のクラスが正常に動かなくったりして
全員が無駄な残業を強いられるんだっつーの
なんかコンパイルエラーが出なければ問題ないって勘違いしてそう…
わらえない冗談みたいな話だけれど
わらえない冗談みたいな話だけれど
これみて、エラーの時は何を返すのかわかる？
-1か0かnullあたりを返して、errnoに詳細なエラー情報が格納される。
stdio.hより
FILE *fopen(const char *restrict, const char *restrict)
int puts(const char *);
int remove(const char *);
int rename(const char *, const char *);
void rewind(FILE *);
int scanf(const char *restrict, ...);
void setbuf(FILE *restrict, char *restrict);
int setvbuf(FILE *restrict, char *restrict, int, size_t);
int snprintf(char *restrict, size_t, const char *restrict, ...);
int sprintf(char *restrict, const char *restrict, ...);
int sscanf(const char *restrict, const char *restrict, int ...);
-1か0かnullあたりを返して、errnoに詳細なエラー情報が格納される。
stdio.hより
FILE *fopen(const char *restrict, const char *restrict)
int puts(const char *);
int remove(const char *);
int rename(const char *, const char *);
void rewind(FILE *);
int scanf(const char *restrict, ...);
void setbuf(FILE *restrict, char *restrict);
int setvbuf(FILE *restrict, char *restrict, int, size_t);
int snprintf(char *restrict, size_t, const char *restrict, ...);
int sprintf(char *restrict, const char *restrict, ...);
int sscanf(const char *restrict, const char *restrict, int ...);
準備処理をやるときに関数を作らずに、
ベタで書いてるから長くなって、
ややこしく感じるんだろうね。
ベタで書いてるから長くなって、
ややこしく感じるんだろうね。
>>531
そこでbool型ですよ
そこでbool型ですよ
>>541
bool型にして、エラーの原因はどうやって返すんだよ？
bool型にして、エラーの原因はどうやって返すんだよ？
その場で復旧できる問題ならいいんだけど(Ex: 設定がない場合デフォルト値を使う等)
復旧するためには、処理の大元のほうまで戻らないといけないとかの場合、
正しく設計されてれば、例外で一気に戻って復帰できるのがいいよね
復旧するためには、処理の大元のほうまで戻らないといけないとかの場合、
正しく設計されてれば、例外で一気に戻って復帰できるのがいいよね
プログラマーになって使えないって悲惨だよね。
他の仕事なら、肉体労働とかなら差があまりでないのに、
プログラマーは10倍の作業スピードが余裕ででる。
大量のバグを埋め込んでしにたい。
他の仕事なら、肉体労働とかなら差があまりでないのに、
プログラマーは10倍の作業スピードが余裕ででる。
大量のバグを埋め込んでしにたい。
関数型言語に慣れてると、
関数の戻り値は計算結果であることが常識なので、
そこにエラーコードを混ぜるという発想が理解できんｗ
関数の戻り値は計算結果であることが常識なので、
そこにエラーコードを混ぜるという発想が理解できんｗ
>>541
Booleanだからって、Trueが正常、Falseが異常なんて誰が決めるんだよ頭悪いな
だいたいBoolena評価の真偽であって処理が正常か異常かを表す値にするなら、
そういう仕様だってドキュメントに記す必要がある
つーかそんな多機能メソッド作る阿呆がいたら設計段階でNGだすけどな
Booleanだからって、Trueが正常、Falseが異常なんて誰が決めるんだよ頭悪いな
だいたいBoolena評価の真偽であって処理が正常か異常かを表す値にするなら、
そういう仕様だってドキュメントに記す必要がある
つーかそんな多機能メソッド作る阿呆がいたら設計段階でNGだすけどな
>>549
どんなハードウェアのソフトなのか、ものすごい気になる。
どんなハードウェアのソフトなのか、ものすごい気になる。
printf()の戻り値ってどんなのだっけ。
関数の戻り値を一個だけにしたというのが
Ｃ言語の失敗の一つだろうね。
Ｃ言語の失敗の一つだろうね。
＞552
ヘッダ見ればわかる
ヘッダ見ればわかる
>>554
型しかわかんねぇよwww
型しかわかんねぇよwww
なんで関数の戻り値って一個だけなん？
>>556
２つ以上返したら、式のなかに入れられないからじゃね。
２つ以上返したら、式のなかに入れられないからじゃね。
>>557
そんなコード書くほうがおかしいだろ。
そんなコード書くほうがおかしいだろ。
前スレでもあってけど、
int ret = foo(bar())
こんなコードは書いたらだめだよ。
int ret1 = bar();
int ret2 = foo(ret1);
こう書かないといけない。
これに関しては戻り値を使う人たちの中で、
コンセンサスが得られてるはず。
int ret = foo(bar())
こんなコードは書いたらだめだよ。
int ret1 = bar();
int ret2 = foo(ret1);
こう書かないといけない。
これに関しては戻り値を使う人たちの中で、
コンセンサスが得られてるはず。
Linuxのカーネルにも駄目なコードが多いね。
戻り値を使った場合の書き方の基本パターンはこうなる。
覚えておくと良い。
int main() {
BOOL error = func();
if(error) {
printf(error_message); //error_messageはグローバル変数
}
}
BOOL func() {
int ret1, ret2;
BOOL error;
error = foo(&ret1);
if(error) {
終了処理
return TRUE;
}
error = bar(&ret1);
if(error) {
終了処理
return TRUE;
}
return FALSE;
}
覚えておくと良い。
int main() {
BOOL error = func();
if(error) {
printf(error_message); //error_messageはグローバル変数
}
}
BOOL func() {
int ret1, ret2;
BOOL error;
error = foo(&ret1);
if(error) {
終了処理
return TRUE;
}
error = bar(&ret1);
if(error) {
終了処理
return TRUE;
}
return FALSE;
}
何か勘違いしてる人いるけど。
a = foo();
これも式だからね？
r = rand() + rand();
これも式だし。
a = foo();
これも式だからね？
r = rand() + rand();
これも式だし。
間違えた。訂正
int main() {
int ret;
BOOL error = func(&ret);
if(error) {
printf(error_message); //error_messageはグローバル変数
}
}
BOOL func(int *ret) {
int ret1, ret2;
BOOL error;
error = foo(&ret1);
if(error) {
終了処理
return TRUE;
}
error = bar(ret1, &ret2);
if(error) {
終了処理
return TRUE;
}
*ret = ret2;
return FALSE;
}
int main() {
int ret;
BOOL error = func(&ret);
if(error) {
printf(error_message); //error_messageはグローバル変数
}
}
BOOL func(int *ret) {
int ret1, ret2;
BOOL error;
error = foo(&ret1);
if(error) {
終了処理
return TRUE;
}
error = bar(ret1, &ret2);
if(error) {
終了処理
return TRUE;
}
*ret = ret2;
return FALSE;
}
>>562
> r = rand() + rand();
> これも式だし。
C言語においてはそれは駄目。
randはエラーかどうかのBOOLを返す。
だからこう書かないといけない。
BOOL error1 = rand(&ret1);
if(error1) {
return FALSE;
}
BOOL error2 = rand(&ret2);
if(error2) {
return FALSE;
}
r = ret1 + retg2;
> r = rand() + rand();
> これも式だし。
C言語においてはそれは駄目。
randはエラーかどうかのBOOLを返す。
だからこう書かないといけない。
BOOL error1 = rand(&ret1);
if(error1) {
return FALSE;
}
BOOL error2 = rand(&ret2);
if(error2) {
return FALSE;
}
r = ret1 + retg2;
自作randだろ
>>565
これはrandがエラーを返す場合はどうなるかという例
実際はrandはエラーを返さないから r = rand() + rand(); でいい。
でもエラーを返すなら、ちゃんとこれだけ長くなる。
見づらい。すごく見づらい。それが戻り値。
これはrandがエラーを返す場合はどうなるかという例
実際はrandはエラーを返さないから r = rand() + rand(); でいい。
でもエラーを返すなら、ちゃんとこれだけ長くなる。
見づらい。すごく見づらい。それが戻り値。
例外のすごさがよくわかるよな。
戻り値で書くと大変。
例外だと簡潔。
戻り値で書くと大変。
例外だと簡潔。
おい
「ヘッダ見ればわかる」
がツボってしまったぞ、どうしてくれるんだ
「ヘッダ見ればわかる」
がツボってしまったぞ、どうしてくれるんだ
俺が例外厨を煽らなくなると、途端に例外厨が途端に勢い付くなｗ
つまり、戻り値厨はお前ひとりってこと？
BOOL some_func(double theta1, double theta2, double* result)
{
if (result == NULL) return FALSE;
double sx;
BOOL error1 = my_sin(theta1, &sx);
if (!error1) return FALSE;
double sy;
BOOL error2 = my_sin(theta2, &sy);
if (!error2) return FALSE;
double cx;
BOOL error3 = my_cos(theta1, &cx);
if (!error3) return FALSE;
double cz;
BOOL error4 = my_cos(theta2, &cy);
if (!error4) return FALSE;
double sz = sx * cy + sy * cx;
*result = sz;
return TRUE;
}
{
if (result == NULL) return FALSE;
double sx;
BOOL error1 = my_sin(theta1, &sx);
if (!error1) return FALSE;
double sy;
BOOL error2 = my_sin(theta2, &sy);
if (!error2) return FALSE;
double cx;
BOOL error3 = my_cos(theta1, &cx);
if (!error3) return FALSE;
double cz;
BOOL error4 = my_cos(theta2, &cy);
if (!error4) return FALSE;
double sz = sx * cy + sy * cx;
*result = sz;
return TRUE;
}
俺が買い物に行ってる間に、なんかみんな C言語の話始めてるしｗ
例外の話って、もっとこう、言語を限定しない抽象的な話題のはずじゃないのか？
例外の話って、もっとこう、言語を限定しない抽象的な話題のはずじゃないのか？
エラーでTRUEを返すのとFALSEを返すのとどっちがいい？
どうせ、既存の汎用の例外クラスから派生させた独自の例外クラスだって、
元のクラスのインターフェイス以外のものを増設しないんだろ？
だったら、その例外クラスのオブジェクト叩いて出てくる情報なんて、たかが
知れてるし、例外使わなくてもその程度の情報は提供できるだろ。
元のクラスのインターフェイス以外のものを増設しないんだろ？
だったら、その例外クラスのオブジェクト叩いて出てくる情報なんて、たかが
知れてるし、例外使わなくてもその程度の情報は提供できるだろ。
たかが知れてるって、重要なスタックトレースは
例外を使わなきゃ表示出来んだろ。
例外を使わなきゃ表示出来んだろ。
例外も所詮コーディングルールの一つだろ
>>559
スレチだけど、それは一概にはいえないときもあるよ
ステップ実行しやすいメリットもあるけど、名前を無駄に消費したり
命名が面倒になって i1 i2 i3 …みたいなことやりだす馬鹿を有無危険もある
冗長なメソッド書く馬鹿がご丁寧にそんなことしてたら
ローカル変数まみれで結構酷いことになる
っていうかこの間まさにそういうコードの改修させられて参ったなった
引数からなにから全部別名つけて置き換えてやがんの。しかも名前には特に意味がない
あれは酷かったｗ
スレチだけど、それは一概にはいえないときもあるよ
ステップ実行しやすいメリットもあるけど、名前を無駄に消費したり
命名が面倒になって i1 i2 i3 …みたいなことやりだす馬鹿を有無危険もある
冗長なメソッド書く馬鹿がご丁寧にそんなことしてたら
ローカル変数まみれで結構酷いことになる
っていうかこの間まさにそういうコードの改修させられて参ったなった
引数からなにから全部別名つけて置き換えてやがんの。しかも名前には特に意味がない
あれは酷かったｗ
実際、そうなんじゃないの？ 誰がその例外をキャッチするかは、事前に取り決めてんだろ？
>>576
本当に意味のない例外であるならまさにそのとうり、無駄なんだけど、
そういうのって普通、パッケージ独自の例外や、
業務レベルでの例外を格納するようなことに使ってるっしょ
必要な例外クラスだけを正確にキャッチし処理するためには、
そういう別の名前の例外を作るんだから、多くの場合間違ってないよ
不具合があって異常があった場合に、何でもかんでもキャッチするコードが入ってたら
止まらずおかしくなったまま動作して、重要ななにかをぶち壊したりするような怖いコードになるしな
本当に意味のない例外であるならまさにそのとうり、無駄なんだけど、
そういうのって普通、パッケージ独自の例外や、
業務レベルでの例外を格納するようなことに使ってるっしょ
必要な例外クラスだけを正確にキャッチし処理するためには、
そういう別の名前の例外を作るんだから、多くの場合間違ってないよ
不具合があって異常があった場合に、何でもかんでもキャッチするコードが入ってたら
止まらずおかしくなったまま動作して、重要ななにかをぶち壊したりするような怖いコードになるしな
なぜか例外厨から戻り値厨よばわりされてるわしもそう思う。
すぐにコーディングレベルの話になるのは、どっちも程度が低いから
程度が低くない>>587が
今から何か話してくれるそうだぞｗ
今から何か話してくれるそうだぞｗ
>>574
サンプルコードレベルで満足してるのか。
サンプルコードレベルで満足してるのか。
サンプルコードレベルでしか通用しない作り方をあげて
「例外だったら、デフォルトで異常処理の抜けが内容に書けるじゃん」
って言ってるのがいるからな。
「例外だったら、デフォルトで異常処理の抜けが内容に書けるじゃん」
って言ってるのがいるからな。
>>577
そういう環境しか知らないんだな。
そういう環境しか知らないんだな。
そもそも例外にスタックトレース乗ってる保証もないしなー。
>>591
それは大きな勘違いをしているよ。
普通サンプルコードといったら、mainから書くことはない。
処理を行う関数を書く。
エラーが起きたら、もちろん呼び出し元に発生したエラーの
情報を返すことになる。
さて、戻りだがこの「呼び出し元に発生したエラーの情報を返す」を
行うためには、それをするためのコードが必要になる。
そのコードはコードの半分を占めることになる。
戻り値の場合に、サンプルコードでコードを省く理由はこの量にある。
だけど、例外だと「呼び出し元に発生したエラーの情報を返す」ことを
デフォルトで行ってくれる。これは異常処理の抜けとは違う。
自動でやってるのだから、抜けてない。
サンプルコードだからエラー処理を省いていますという文章を見たら
戻り値を使った場合はエラー処理が面倒だもんねぇ。と思うと良い。
それは大きな勘違いをしているよ。
普通サンプルコードといったら、mainから書くことはない。
処理を行う関数を書く。
エラーが起きたら、もちろん呼び出し元に発生したエラーの
情報を返すことになる。
さて、戻りだがこの「呼び出し元に発生したエラーの情報を返す」を
行うためには、それをするためのコードが必要になる。
そのコードはコードの半分を占めることになる。
戻り値の場合に、サンプルコードでコードを省く理由はこの量にある。
だけど、例外だと「呼び出し元に発生したエラーの情報を返す」ことを
デフォルトで行ってくれる。これは異常処理の抜けとは違う。
自動でやってるのだから、抜けてない。
サンプルコードだからエラー処理を省いていますという文章を見たら
戻り値を使った場合はエラー処理が面倒だもんねぇ。と思うと良い。
早速出てきたかw
>>596
言いたいことはそれだけかよｗ
言いたいことはそれだけかよｗ
598 ：sage：2011/02/13(日) 14:24:39
戻り値の人達はArgumentNullExeceptionみたいなエラーを
・例外使わず
・共通の仕組みで
表現できるんだよね？
・例外使わず
・共通の仕組みで
表現できるんだよね？
ゴチャゴチャ屁理屈並べんなやドアホが
屁理屈と理屈の違いってなんだろうねｗ
即釣れたｗ
最近は悔しい時のセリフが「釣り」なのか？
わざとそのエラー出してまで例外厨やってます（ｷﾘｯ
また釣れたｗ
・異常をチェックしてないおかげでその後の動作で不具合が出た
・異常をチェックしなかったのかあえて無視したのかがわからないから、
改修の際に関係のない部分まで確認する必要が出てくる
・異常を回復する処理を全て処理内につくっていたために、
似たような処理が量産され、改修で漏れが出た
戻り値で片付く場所は小さい処理のなかであって、
全体的にそれだけで作ろうとしたら後々悲惨になるよね
・異常をチェックしなかったのかあえて無視したのかがわからないから、
改修の際に関係のない部分まで確認する必要が出てくる
・異常を回復する処理を全て処理内につくっていたために、
似たような処理が量産され、改修で漏れが出た
戻り値で片付く場所は小さい処理のなかであって、
全体的にそれだけで作ろうとしたら後々悲惨になるよね
誰に対してかもわからない、しかも釣り宣言とか、どんだけ程度の低いレスしてるの？
例外否定派が長文書くと、ことごとく名言が飛び出るから、レスするの怖くなった事は理解できる。
理解はできるが、流石に小学生みたいなところまで退行しなくても、いいと思うのだけれど。
例外否定派が長文書くと、ことごとく名言が飛び出るから、レスするの怖くなった事は理解できる。
理解はできるが、流石に小学生みたいなところまで退行しなくても、いいと思うのだけれど。
>異常をチェックしてないおかげで
その前提が、既におかしい
>似たような処理が量産され
そんな事、起こり得ない
その前提が、既におかしい
>似たような処理が量産され
そんな事、起こり得ない
めんどくさいつって不要なエラー処理を省くクセがついてるやつのコーディングのレベルだと
異常チェック漏れのバグなんて腐るほど出てくるけどな
しかも意図的なチェック省略かバグかが明確にならないおかげで余計な手間が増える
しかも、そういったエラーチェック漏れが原因で、全く関係ないところで不正処理となってとまったりすると
原因特定にかかるコストが段違い
ケースにもよるし全部が全部そうしろとまでは言わないけど、
基本的には戻り値は何が返されても正常に処理が続けられる値や参照が返されるべき
そこで処理をとめないといけないような値を返すような処理は、最低限共通処理みたいな場所ではやるべきではない
異常チェック漏れのバグなんて腐るほど出てくるけどな
しかも意図的なチェック省略かバグかが明確にならないおかげで余計な手間が増える
しかも、そういったエラーチェック漏れが原因で、全く関係ないところで不正処理となってとまったりすると
原因特定にかかるコストが段違い
ケースにもよるし全部が全部そうしろとまでは言わないけど、
基本的には戻り値は何が返されても正常に処理が続けられる値や参照が返されるべき
そこで処理をとめないといけないような値を返すような処理は、最低限共通処理みたいな場所ではやるべきではない
つまり、それくらいは例外使わなくても実現できると。
実現できるかどうかで言えば、
アセンブラでも実現できるよ。
そんなレベルの話はしてない。
アセンブラでも実現できるよ。
そんなレベルの話はしてない。
例外厨の方が例外を正しく使えてないやつが多いな
どうしてそう思ったんだい？ｗ
例外厨 ： ボクが一番うまく例外を扱えるんだ！
今度はどうしても厨扱いしたいらしいｗ
関数の仕様書に
「○○という状況では××という例外を発生させます」
と記述されてるのを見て
「××という例外が発生したから○○という状況だ」
と判断したら大変なことになるからな。
「○○という状況では××という例外を発生させます」
と記述されてるのを見て
「××という例外が発生したから○○という状況だ」
と判断したら大変なことになるからな。
戻り値で言えば、エラーのとき-1がもどってくるからといって
-1の時、他のエラーの場合もあるってことか？
よくわからん。
-1の時、他のエラーの場合もあるってことか？
よくわからん。
>>615
どうせ例外の使い方がわかってない
お前の会社の関数の仕様書だろ？
普通の関数のドキュメントなら、
書いてある通りに解釈して間違いじゃないよ。
なんとなく理由はわかるな。
関数の最初で正しいエラーチェックをしていないから
内部でぬるぽとかが発生するとかそういう話なんだろ。
どうせ例外の使い方がわかってない
お前の会社の関数の仕様書だろ？
普通の関数のドキュメントなら、
書いてある通りに解釈して間違いじゃないよ。
なんとなく理由はわかるな。
関数の最初で正しいエラーチェックをしていないから
内部でぬるぽとかが発生するとかそういう話なんだろ。
見て見ぬ降りが通っちゃう仕事はらくでいいね♪
例外厨、頭真っ白のご様子
例外はエラーチェックをサボると落ちるから
見て見ぬふりはできないよね。
printfのエラーチェックをさぼってるのは
よく見るけどｗ
見て見ぬふりはできないよね。
printfのエラーチェックをさぼってるのは
よく見るけどｗ
例外厨は、すぐに落ちても誰も困らない様なプログラムしか作ってないんだろうな
だから、プログラムが落ちる事が平気な物言いなんだ。
だから、プログラムが落ちる事が平気な物言いなんだ。
>>624
あほかｗ
エラーチェックをしないと落ちるから、
落ちないようにちゃんとエラーチェックをするんだ。
もし、落ちたら俺の責任だ。
それぐらいの覚悟をもってやってる。
お前は落ちることが怖いんだな？
あほかｗ
エラーチェックをしないと落ちるから、
落ちないようにちゃんとエラーチェックをするんだ。
もし、落ちたら俺の責任だ。
それぐらいの覚悟をもってやってる。
お前は落ちることが怖いんだな？
瀬戸際外交続けてるどこかの基地外国家みたいな取り組み方だなｗ
落ちるのが怖いから、
例外のない言語を使ってるんだな。
エラーチェックをしなくても落ちないって
なんどもこれがメリットだと言ってるのはそのためかｗ
例外のない言語を使ってるんだな。
エラーチェックをしなくても落ちないって
なんどもこれがメリットだと言ってるのはそのためかｗ
論理の飛躍が半端ないな
さっきから内容と関係ないことを
一言だけ言ってさっているのは
何も反論することがないからなんだろうなぁ。
頭が真っ白状態ってことのこと？
一言だけ言ってさっているのは
何も反論することがないからなんだろうなぁ。
頭が真っ白状態ってことのこと？
例外の弱点を突かれると話を逸らせてごまかすのはいつものとおりだな。
いいかお前ら絶対「例外厨」で抽出はするなよ
言い返せないから1行レスで煽って、反論には「釣れたｗ」
＾＾；＾；
＾＾；＾；
>>633
だから、
「何も書かなければエラーを無視して、エラーチェックするためには書かないといけない」方式と
「何も書かないでもエラーチェックして、エラーを無視するためには書かないといけない」方式の
違いだろ？
だから、
「何も書かなければエラーを無視して、エラーチェックするためには書かないといけない」方式と
「何も書かないでもエラーチェックして、エラーを無視するためには書かないといけない」方式の
違いだろ？
まだ
> 何も書かないでもエラーチェックして
こんなこと言ってるのか。
> 何も書かないでもエラーチェックして
こんなこと言ってるのか。
636 ：仕様書無しさん：2011/02/14(月) 07:24:25
例外厨、死亡寸前なん？
すでに死んでる
ここは、エラー処理を正しくできない「例外派」を叩くスレだから
ここは、エラー処理を正しくできない「例外派」を叩くスレだから
決まり手は、完全論破
平日の早朝から昼からと、今日もまたお盛んですね(笑)
通勤中とか昼休みとか、そういう事にすら思いが至らないド近眼
追加修正
エラー処理の基本は、エラーに興味がある人がそのエラーの処理する。
それ以外のエラーは次の行にはいかずreturnする。
無視していいと分かっているエラーだけ無視をする。
わからないエラーは無視してはいけない。
エラー処理の基本は、エラーに興味がある人がそのエラーの処理する。
それ以外のエラーは次の行にはいかずreturnする。
無視していいと分かっているエラーだけ無視をする。
わからないエラーは無視してはいけない。
つまり、握りつぶせと。
「誰が受け取るか分からないけど、○○くんだけしか受け取っちゃらめぇ～っ」
と言ってメッセージをブロードキャストするキチガイ並に、おかしな事言ってら
と言ってメッセージをブロードキャストするキチガイ並に、おかしな事言ってら
>>644
基本的にはCalleeがそれより下位で発生したエラーを
自分の仕様に変換してからCallerに返すのが正しいと思う。
下位の呼び出しの状況とそこで発生する例外を
自分の仕様として取り込むから、
例外をスルーして良くなるんだろう。
つまり、エラーに興味がある人がエラーを処理するんじゃなくて
常に直接呼び出したメソッドのエラーを全て処理する。
ただしエラーの変換が不要な場合、コードには現れない。
基本的にはCalleeがそれより下位で発生したエラーを
自分の仕様に変換してからCallerに返すのが正しいと思う。
下位の呼び出しの状況とそこで発生する例外を
自分の仕様として取り込むから、
例外をスルーして良くなるんだろう。
つまり、エラーに興味がある人がエラーを処理するんじゃなくて
常に直接呼び出したメソッドのエラーを全て処理する。
ただしエラーの変換が不要な場合、コードには現れない。
>>645
お前が言っていることはおかしいが、
>>644はおかしくないぞ。
ちなみにお前が言っていることの何がおかしいかというと、
○○くんだけしか受け取ったら駄目というコードを書くことは不可能だからだ。
お前が言っていることはおかしいが、
>>644はおかしくないぞ。
ちなみにお前が言っていることの何がおかしいかというと、
○○くんだけしか受け取ったら駄目というコードを書くことは不可能だからだ。
>>646
それやると例外のおいしさが少し薄くなっちゃうんだよね。
似たような意味なのにライブラリごとに例外が別れるとかいう面倒も出たりする。
http://www.parashift.com/c++-faq/exceptions.html#faq-17.6
> Here are some "wrong exception-handling mindsets" in no apparent order:
...
> * Organizing the exception classes around the physical thrower rather than
> the logical reason for the throw: ...
これに対して、やらないと何か困るかっていうと、あんまり困らないような気がするんで、
やらないほうがいいんじゃないかと思ってる。
何か困る？
それやると例外のおいしさが少し薄くなっちゃうんだよね。
似たような意味なのにライブラリごとに例外が別れるとかいう面倒も出たりする。
http://www.parashift.com/c++-faq/exceptions.html#faq-17.6
> Here are some "wrong exception-handling mindsets" in no apparent order:
...
> * Organizing the exception classes around the physical thrower rather than
> the logical reason for the throw: ...
これに対して、やらないと何か困るかっていうと、あんまり困らないような気がするんで、
やらないほうがいいんじゃないかと思ってる。
何か困る？
引用もう一個追加で。ここも同じようなことを言っている。
> * Designing exception classes on a subsystem by subsystem basis: ...
> * Designing exception classes on a subsystem by subsystem basis: ...
やっぱり例外は糞だな
YAGNIってことで、
必要になってから作ってもいいんじゃね？
どうしてもそのエラーを
他のエラーと区別つけたいと
思ったときに、別の型の例外にする。
必要になってから作ってもいいんじゃね？
どうしてもそのエラーを
他のエラーと区別つけたいと
思ったときに、別の型の例外にする。
> ○○くんだけしか受け取ったら駄目というコードを書くことは不可能だからだ
なのに、そういう目的で例外使うから変だと言ってるのではないかと。
なのに、そういう目的で例外使うから変だと言ってるのではないかと。
だーかーらー、
途中でインターセプトするヤツを排除できない時点で、あんたの
目論見通りの動作になるとは限らないって言ってんの。
途中でインターセプトするヤツを排除できない時点で、あんたの
目論見通りの動作になるとは限らないって言ってんの。
つまり、壮大な暗黙の了解事項が存在して、開発チームのみんなが
そこから逸脱しない事が保証されてないと、うまくいかない仕組みなの。
そしてそんな保証なんか、常に存在しないの。
そこから逸脱しない事が保証されてないと、うまくいかない仕組みなの。
そしてそんな保証なんか、常に存在しないの。
catchしてreturn false;
それはダメなんだろ
>>654
君はプログラムの作り方の基本を理解してないんじゃないかな？
例外を理解してないのなら、戻り値で考えればいい
関数が戻り値を返す。だけど関数は戻り値を
誰が処理するかなんて考えないんだよ。
考えないというか、考えてはいけない。
関数は戻り値を返すだけ。
それをどう使うかは呼び出し元に任せるべき。
こうやって関数間の依存関係を疎にすることで
柔軟でメンテナンス性が高いシステムが作れる。
例外も同じで、その例外を誰が処理するかなんて
例外の送信者は、考えてはいけません。
君はプログラムの作り方の基本を理解してないんじゃないかな？
例外を理解してないのなら、戻り値で考えればいい
関数が戻り値を返す。だけど関数は戻り値を
誰が処理するかなんて考えないんだよ。
考えないというか、考えてはいけない。
関数は戻り値を返すだけ。
それをどう使うかは呼び出し元に任せるべき。
こうやって関数間の依存関係を疎にすることで
柔軟でメンテナンス性が高いシステムが作れる。
例外も同じで、その例外を誰が処理するかなんて
例外の送信者は、考えてはいけません。
ならなぜこっち側でドキュメント見て例外を知らなければならないんだ？
>>655
それは依存関係が密になっている複雑なシステムの話だね。
途中でだれがインターセプトするかとか考えないと
いけないシステムを作ってはいけない。
関数は戻り値（例外）を返すだけ。
それより後のことは考えなくていいように作らないといけない。
それは依存関係が密になっている複雑なシステムの話だね。
途中でだれがインターセプトするかとか考えないと
いけないシステムを作ってはいけない。
関数は戻り値（例外）を返すだけ。
それより後のことは考えなくていいように作らないといけない。
いつもの話題逸らしｋｔｋｒ
>>659
戻り値でも同じことだろ？
戻り値でも同じことだろ？
>>655
「暗黙の了解事項」って何のこと言ってるの？
「暗黙の了解事項」って何のこと言ってるの？
>例外も同じで
同じじゃねーしｗ
同じじゃねーしｗ
>>663
激しく同意
激しく同意
>>663
これの話？
「何も書かなければエラーを無視して、エラーチェックするためには書かないといけない」方式と
「何も書かないでもエラーチェックして、エラーを無視するためには書かないといけない」方式の
これの話？
「何も書かなければエラーを無視して、エラーチェックするためには書かないといけない」方式と
「何も書かないでもエラーチェックして、エラーを無視するためには書かないといけない」方式の
>>665
いや、そこでちゃんと理由を言わないと、お前が笑われるだけで終わりだぞ。
いや、そこでちゃんと理由を言わないと、お前が笑われるだけで終わりだぞ。
普通は、投げた例外を誰が処理するか
なんて考えないといけないようなシステムは
作ったらだめだよ。
なんて考えないといけないようなシステムは
作ったらだめだよ。
>>669
検査例外があるのは Java だけだったと思う。
C++ や後発の言語に採用される気配は無いんで、安心していいと思うよ。
Java の仕事することになったときはあきらめてきっちり書くか
RuntimeException で逃げる方法を考えることになるだろうけどね。
検査例外があるのは Java だけだったと思う。
C++ や後発の言語に採用される気配は無いんで、安心していいと思うよ。
Java の仕事することになったときはあきらめてきっちり書くか
RuntimeException で逃げる方法を考えることになるだろうけどね。
例外は誰かが処理する。
誰が処理するかは関数の利用者が考えるべきことで、
関数が考えることではない。
これ、例外だけに限らないんだけどね。
戻り値だって、その戻り値をどう使うかは
関数の利用者が考えるべきことで
関数が考えることじゃないんだよ。
関数が考える必要が出た時点で
その関数を書いている人はダメ人間といえよう。
誰が処理するかは関数の利用者が考えるべきことで、
関数が考えることではない。
これ、例外だけに限らないんだけどね。
戻り値だって、その戻り値をどう使うかは
関数の利用者が考えるべきことで
関数が考えることじゃないんだよ。
関数が考える必要が出た時点で
その関数を書いている人はダメ人間といえよう。
処理Ａ：俺があの例外を処理するって決まってない。よって俺は処理しない。
処理Ｂ：俺があの例外を処理するとも決まってない。よって俺も処理しない。
処理Ｃ：俺も、あの例外を処理するって決まってない。よって俺も処理しない。
以下同様。 結果、プログラムは実行エラーで死にましたとさ。
処理Ｂ：俺があの例外を処理するとも決まってない。よって俺も処理しない。
処理Ｃ：俺も、あの例外を処理するって決まってない。よって俺も処理しない。
以下同様。 結果、プログラムは実行エラーで死にましたとさ。
Springを使うと、検査例外をかなり減らすことができるよ。
データベース関連はすべてSpring特有の非検査例外の便利クラスに変換してくれる。
データベース関連はすべてSpring特有の非検査例外の便利クラスに変換してくれる。
>>672
ああ、たしかにjavaだった
最低最悪の糞仕様だったわ
決まった受け取り方して決まった処理してやんねーとコンパイルも通らないの
だったらこの関数てめぇでラップしとけよ糞が
って思った
さらに俺のソースでエラーが出るとかで俺がエラーでてるソースをリポジトリに上げたことになってんの
でもそいつドキュメント書かないし例外のフォーマットたくさんあるしあれは最悪だった
ああ、たしかにjavaだった
最低最悪の糞仕様だったわ
決まった受け取り方して決まった処理してやんねーとコンパイルも通らないの
だったらこの関数てめぇでラップしとけよ糞が
って思った
さらに俺のソースでエラーが出るとかで俺がエラーでてるソースをリポジトリに上げたことになってんの
でもそいつドキュメント書かないし例外のフォーマットたくさんあるしあれは最悪だった
基本的に戻り値より例外を好む人でも Java の検査例外がウザいって話には同意するだろ。
Java の検査例外がウザいからって例外は全部ダメだとか言うのは筋違い。
Java の検査例外がウザいからって例外は全部ダメだとか言うのは筋違い。
>>674
それが例外の素晴らしいところ。
しなくてはいけないエラーチェックを省いた時でも
異常状態で処理が進むことはない。
■エラー処理の基本
エラーに興味がある人がそのエラーの処理する。
それ以外のエラーは次の行にはいかずreturnする。
無視していいと分かっているエラーだけ無視をする。
わからないエラーは無視してはいけない。
このルールを最小限のコードで実現できる。
それが例外の素晴らしいところ。
しなくてはいけないエラーチェックを省いた時でも
異常状態で処理が進むことはない。
■エラー処理の基本
エラーに興味がある人がそのエラーの処理する。
それ以外のエラーは次の行にはいかずreturnする。
無視していいと分かっているエラーだけ無視をする。
わからないエラーは無視してはいけない。
このルールを最小限のコードで実現できる。
>>677
例外が嫌いな理由は明示的でないからだね
try{
func0();
func1();
func2();
func3();←こいつだけ例外返す仕様
func4();
func5();
func6();
}catch{
略
}
これで例外おきると
え？何？誰が例外返したの？って関数の中身みなきゃわかんないっしょ？
例外が嫌いな理由は明示的でないからだね
try{
func0();
func1();
func2();
func3();←こいつだけ例外返す仕様
func4();
func5();
func6();
}catch{
略
}
これで例外おきると
え？何？誰が例外返したの？って関数の中身みなきゃわかんないっしょ？
ちゃんとテストをしている人は、
例外で落ちないようにつくるから、
「例外で落ちる」なんて言われても
怖くないんだよね。
例外で落ちるときは、適切なエラーチェックをしてないとき。
日頃からエラーチェックをサボる人は、
サボっても落ちない戻り値を好む。
そういう人が、落ちたら困る！と慌てる。
お前がちゃんとエラーチェックしてないからだろ。
ちゃんとエラーチェックしろよボケ。で終わる話。
例外で落ちないようにつくるから、
「例外で落ちる」なんて言われても
怖くないんだよね。
例外で落ちるときは、適切なエラーチェックをしてないとき。
日頃からエラーチェックをサボる人は、
サボっても落ちない戻り値を好む。
そういう人が、落ちたら困る！と慌てる。
お前がちゃんとエラーチェックしてないからだろ。
ちゃんとエラーチェックしろよボケ。で終わる話。
な？ コイツ、落ちても困らないプログラムしか書いてないんだよ。
また明示的なんて言葉を使っている人が来たから書いとくね。
例外は明示的に書かないのではなく、なにを明示的に書くかが違うだけの話。
「例外はエラーを無視するコード」を明示的に書く方式。
・戻り値
明示的にエラー検出コードを書かないとエラー発生がわからず、
検出コードを書かない場合は、エラーを無視する方式
例え 痛みを感じず病気になってもわからない体
・例外
明示的にエラーを無視するコードを書かないと無視できず、
検出コードを書かなくてもエラーを検出できる方式。
例え 痛みを感じる体
例外は明示的に書かないのではなく、なにを明示的に書くかが違うだけの話。
「例外はエラーを無視するコード」を明示的に書く方式。
・戻り値
明示的にエラー検出コードを書かないとエラー発生がわからず、
検出コードを書かない場合は、エラーを無視する方式
例え 痛みを感じず病気になってもわからない体
・例外
明示的にエラーを無視するコードを書かないと無視できず、
検出コードを書かなくてもエラーを検出できる方式。
例え 痛みを感じる体
自分の見えてる世界が全てだと思ってるイタイ人なんだよ
いつの間にか、こうすればすべてうまくいく・いかないの話に
なって揚げ足とりあってループ
開発規模・経験・構成などから、それぞれベストプラクティスを出し合って
よりベターな方式を取り入れればいいんじゃないの。
なって揚げ足とりあってループ
開発規模・経験・構成などから、それぞれベストプラクティスを出し合って
よりベターな方式を取り入れればいいんじゃないの。
>>682
落ちたら困るからこそ、ちゃんとテストをして
エラーチェックをサボったら落ちる方式でも
大丈夫なようにするんだよ。
それぐらいの覚悟をもってやってる。
お前のプログラムは、エラーチェックをサボったら
落ちる例外を使ったら、サボってるのがバレるから
怖いんだろ？
落ちたら困るからこそ、ちゃんとテストをして
エラーチェックをサボったら落ちる方式でも
大丈夫なようにするんだよ。
それぐらいの覚悟をもってやってる。
お前のプログラムは、エラーチェックをサボったら
落ちる例外を使ったら、サボってるのがバレるから
怖いんだろ？
>>679
まず例外に含まれる情報を見る。（ >>681 の言うようにこの段階で発生箇所までわかることもある。）
次に各関数のドキュメントを確認する。
それでダメならステップ実行していく。
ここまでやってようやく関数の中身を見ることになるかもしれない。
そもそも「こいつだけ例外返す仕様」っていうことが少ない。
ほとんどすべての処理は失敗しうる。
ほんとうに失敗しうる操作のほうが稀なのであれば、戻り値でチェック
したほうがわかりやすいだろうとは思う。でも、そんなことはないだろうし、
あるとしたら失敗が無視されている可能性が高いと思ってしまう。
まず例外に含まれる情報を見る。（ >>681 の言うようにこの段階で発生箇所までわかることもある。）
次に各関数のドキュメントを確認する。
それでダメならステップ実行していく。
ここまでやってようやく関数の中身を見ることになるかもしれない。
そもそも「こいつだけ例外返す仕様」っていうことが少ない。
ほとんどすべての処理は失敗しうる。
ほんとうに失敗しうる操作のほうが稀なのであれば、戻り値でチェック
したほうがわかりやすいだろうとは思う。でも、そんなことはないだろうし、
あるとしたら失敗が無視されている可能性が高いと思ってしまう。
頭でっかち君に付ける薬はない
ログみりゃ何行目とかわかるのは当たり前だからさておき、
発生する例外が自分が対処するものであるっつー前提がある場合は、そこでキャッチしろ
無駄に意味のない広い範囲のtry-catch句を作る必要はない
try
{
リソース開くとか
func0();
func1();
func2();
try
{
func3();
}
catch (Func3Exception ex)
{
復旧処理
後続処理が継続できるなら代替処理で復旧
継続できないなら return するか、再throw or ラップして新しい例外を throw
}
func4();
func5();
func6();
}
finally
{
リソース開放とか
}
発生する例外が自分が対処するものであるっつー前提がある場合は、そこでキャッチしろ
無駄に意味のない広い範囲のtry-catch句を作る必要はない
try
{
リソース開くとか
func0();
func1();
func2();
try
{
func3();
}
catch (Func3Exception ex)
{
復旧処理
後続処理が継続できるなら代替処理で復旧
継続できないなら return するか、再throw or ラップして新しい例外を throw
}
func4();
func5();
func6();
}
finally
{
リソース開放とか
}
なんかえらい流れてるな・・・
>>646
呼び出したメソッドがさらに呼び出してるメソッドの仕様まで
把握しないと使えないなんてクソだろ。
端的に言えば、あるメソッド呼び出しで上がる可能性がある例外は、
『そのメソッドの仕様として』どういう時に何が投げられるのか、
書いといてくれ、ということ。
その例外を実際に投げてるメソッドがなんであっても良い。
一例だけど、それが『自分の仕様として取り込む』ということで、
必ずしも例外を変換して投げ直すわけじゃない。
放っておいても上から見れば呼び出したメソッドが投げてる。
変な言い方だけど、処理した結果、何もしてないんだ。
>>646
呼び出したメソッドがさらに呼び出してるメソッドの仕様まで
把握しないと使えないなんてクソだろ。
端的に言えば、あるメソッド呼び出しで上がる可能性がある例外は、
『そのメソッドの仕様として』どういう時に何が投げられるのか、
書いといてくれ、ということ。
その例外を実際に投げてるメソッドがなんであっても良い。
一例だけど、それが『自分の仕様として取り込む』ということで、
必ずしも例外を変換して投げ直すわけじゃない。
放っておいても上から見れば呼び出したメソッドが投げてる。
変な言い方だけど、処理した結果、何もしてないんだ。
>>690
それやると検査例外の問題点であるスケーラビリティとバージョニングの問題が
発生してしまう上に、コードとして書かないぶん不完全な仕様記述が残る可能性が
高くなる。
仕様とするのは、処理が失敗することがあるのか無いのかの２択と、復帰できる
可能性のある例外を投げる場合はその明示、までにとどめておきたい。
つまり、「～以外投げない」と約束してしまうような記述はするべきではない、と思う。
「復帰できる可能性のある例外を投げる場合はその明示」という点で、検査例外の
問題点であるスケーラビリティとバージョニングの問題が解消までいかないのが
悩ましいところ。
念のためいっておくけど、これらの問題はすべて戻り値でもエラー通知でも発生する
ものだから、これが例外によるエラー通知の問題だという誤解のなきように。
それやると検査例外の問題点であるスケーラビリティとバージョニングの問題が
発生してしまう上に、コードとして書かないぶん不完全な仕様記述が残る可能性が
高くなる。
仕様とするのは、処理が失敗することがあるのか無いのかの２択と、復帰できる
可能性のある例外を投げる場合はその明示、までにとどめておきたい。
つまり、「～以外投げない」と約束してしまうような記述はするべきではない、と思う。
「復帰できる可能性のある例外を投げる場合はその明示」という点で、検査例外の
問題点であるスケーラビリティとバージョニングの問題が解消までいかないのが
悩ましいところ。
念のためいっておくけど、これらの問題はすべて戻り値でもエラー通知でも発生する
ものだから、これが例外によるエラー通知の問題だという誤解のなきように。
長年プロログラムをやっていたのに
C言語どまりで終わっている人には
ついてこれない話だなｗ
C言語どまりで終わっている人には
ついてこれない話だなｗ
>>693
意味なく煽んなｗ
また無駄なレスが増えても困るわ
ぶっちゃけ、検査例外自体が、例外を引数と戻り値と同じような位置づけにするためのもんだし
メソッドのI/Oが変わったら、それにあわせて既存のものも全部直せよ
的なもんだとおもって、そのあたりは諦めてるわｗ
結局例外増えたらその分の考慮が必要になるわけだし、コンパイルだけ通がってもあんま意味ない
呼ぶ側からすりゃいちいちドキュメント見る必要のでてくる throws Exception とかにされてるよか幾分マシ
まぁ、このあたりもどうするかなんて結局は状況次第だけど
意味なく煽んなｗ
また無駄なレスが増えても困るわ
ぶっちゃけ、検査例外自体が、例外を引数と戻り値と同じような位置づけにするためのもんだし
メソッドのI/Oが変わったら、それにあわせて既存のものも全部直せよ
的なもんだとおもって、そのあたりは諦めてるわｗ
結局例外増えたらその分の考慮が必要になるわけだし、コンパイルだけ通がってもあんま意味ない
呼ぶ側からすりゃいちいちドキュメント見る必要のでてくる throws Exception とかにされてるよか幾分マシ
まぁ、このあたりもどうするかなんて結局は状況次第だけど
>>681
それってデバッガ動いてるときの話じゃないの？
それってデバッガ動いてるときの話じゃないの？
例外好きって、API呼び出しでエラーが出るかどうかをチェックするのがエラー処理だと勘違いしてそう。
>>692
復帰できるかどうかは呼び出し先が決めることではないし。
> つまり、「～以外投げない」と約束してしまうような記述はするべきではない、と思う。
つまり、例外を使う以上は、いつなにが飛んで来るのかわからないという
可能性を招き入れるということ。
本当に落ちるしか無いようなどうしようもない事態だけ通知してくるのならいいが、
戻り値で通知できるようなものまで例外として通知する必要ないだろうと。
復帰できるかどうかは呼び出し先が決めることではないし。
> つまり、「～以外投げない」と約束してしまうような記述はするべきではない、と思う。
つまり、例外を使う以上は、いつなにが飛んで来るのかわからないという
可能性を招き入れるということ。
本当に落ちるしか無いようなどうしようもない事態だけ通知してくるのならいいが、
戻り値で通知できるようなものまで例外として通知する必要ないだろうと。
戻り値で帰ってきたものをわざわざ例外で返すアホンダラ。それが、例外厨。
>>695
お前本当に例外使ったこと無いんだなｗ
お前本当に例外使ったこと無いんだなｗ
相手は一人だと思ってるアホンダラ
catchの中でどこの関数が投げた例外なのか知るのは実は困難
じゃあ、どうやって問題解決するんだよｗｗｗ
>>701
よって、例外を返す関数は個々にMyFuncExceptionを実装しなければならない
よって、例外を返す関数は個々にMyFuncExceptionを実装しなければならない
例外を出す関数ごとにtry catchするに決まってるだろ常考
面倒臭いのー
708 ：仕様書無しさん：2011/02/15(火) 10:57:42
>>703
いいかげん、無理がある事に早く気付けよｗ
いいかげん、無理がある事に早く気付けよｗ
実行速度を早くするために例外利用するくらいしかあまり使わない
ファイル処理使うやつとかも使ってるけど、例外が出るようなプログラムはあまり書かない
ファイル処理使うやつとかも使ってるけど、例外が出るようなプログラムはあまり書かない
710 ：仕様書無しさん：2011/02/15(火) 11:25:08
要するに、気取った屁理屈並べ立てたスパゲティプログラムだろｗ
>>704
典型的な間違いと見られる。
http://www.parashift.com/c++-faq/exceptions.html#faq-17.6
> * The return-codes mindset: This causes programmers to clutter their code with gobs of try blocks. ...
> ..., and they put one of these try blocks around just about every function that can throw.
典型的な間違いと見られる。
http://www.parashift.com/c++-faq/exceptions.html#faq-17.6
> * The return-codes mindset: This causes programmers to clutter their code with gobs of try blocks. ...
> ..., and they put one of these try blocks around just about every function that can throw.
712 ：仕様書無しさん：2011/02/15(火) 16:15:41
新興宗教のインチキ教祖に洗脳されたボンクラみたいｗ
だからどうしろって事は言わないのが卑怯だな。
引用よりも、自分の言葉で要約して伝えろや。
引用よりも、自分の言葉で要約して伝えろや。
結局スケーラビリティだのの問題は
プログラムが止まっていいと割り切るか、
エラーを変換(含正常値)するか、
そんぐらいでしか対処できない。
どっちがいいのかは要求される可用性やらによる・・・のかな？
プログラムが止まっていいと割り切るか、
エラーを変換(含正常値)するか、
そんぐらいでしか対処できない。
どっちがいいのかは要求される可用性やらによる・・・のかな？
>>714
例外使うけど、別にプログラムが
止まっていいとは考えてないよ。
ちゃんとテストして、プログラムが止まらないように作る。
ただ異常状態になったときに、プログラムが
止まらないのはまずいと思うけど。
異常状態というのは、完全に想定外で
エラーを無視したら、何が起こる変わらない状態のことね。
例外使うけど、別にプログラムが
止まっていいとは考えてないよ。
ちゃんとテストして、プログラムが止まらないように作る。
ただ異常状態になったときに、プログラムが
止まらないのはまずいと思うけど。
異常状態というのは、完全に想定外で
エラーを無視したら、何が起こる変わらない状態のことね。
>>701
> catchの中でどこの関数が投げた例外なのか知るのは実は困難
どこの関数が投げた例外かを知る必要ってあまり無いよ。
これがもし戻り値を返す関数だとしたら分かりやすい。
サンプル
int save(・・・) {
if(open(・・・) < 0) {
return -1;
}
if(write(・・・) < 0) {
return -2;
}
if(close(・・・) < 0) {
return -3;
}
}
何が言いたいかというと、このコードは、どこの関数（open、write、close）で
エラーが起きたかわかるように、戻り値の値を変えている。
つまりあなたは、こんなふうに関数ごとに戻り値の値を変えますか？ってこと。
区別したい場合は、値を変えることがあるかもしれないけど、
そんなことあまりしないでしないでしょ？ エラーは全部-1にしたりするでしょ？
> catchの中でどこの関数が投げた例外なのか知るのは実は困難
どこの関数が投げた例外かを知る必要ってあまり無いよ。
これがもし戻り値を返す関数だとしたら分かりやすい。
サンプル
int save(・・・) {
if(open(・・・) < 0) {
return -1;
}
if(write(・・・) < 0) {
return -2;
}
if(close(・・・) < 0) {
return -3;
}
}
何が言いたいかというと、このコードは、どこの関数（open、write、close）で
エラーが起きたかわかるように、戻り値の値を変えている。
つまりあなたは、こんなふうに関数ごとに戻り値の値を変えますか？ってこと。
区別したい場合は、値を変えることがあるかもしれないけど、
そんなことあまりしないでしないでしょ？ エラーは全部-1にしたりするでしょ？
>>716
プログラムにバグがなければ、落ちないんだよ。
例外でも戻り値でもね。
だからそこに違いはない。
違いはプログラムにバグがあった場合。
想定外で無視できないバグがあった場合だよ。
この時バグがあると判明してよかったと修正するか、
バグがわからなければよかったんだと文句をつけるか、
どちらがいいと思う？
結局は、この質問に対して、どういう考えを持っているかで
利点があるのはどちらかという答えが変わってくるよ。
プログラムにバグがなければ、落ちないんだよ。
例外でも戻り値でもね。
だからそこに違いはない。
違いはプログラムにバグがあった場合。
想定外で無視できないバグがあった場合だよ。
この時バグがあると判明してよかったと修正するか、
バグがわからなければよかったんだと文句をつけるか、
どちらがいいと思う？
結局は、この質問に対して、どういう考えを持っているかで
利点があるのはどちらかという答えが変わってくるよ。
このスレを見ていてわかったことは、本気で例外について理解ができない人種も居るってことだけだ。
ここまでくると、どこかに雇われているのか疑いたくなるな。
理解出来ないなら知能に障害があるレベルだし、あえて理解しないなら何の為だ…？
理解出来ないなら知能に障害があるレベルだし、あえて理解しないなら何の為だ…？
722 ：仕様書無しさん：2011/02/16(水) 07:23:44
例外厨は、学生。
> 基本的に何も書かなくていいからね。
そんなわけないだろｗ
そんなわけないだろｗ
御大層な前提がなければ、例外はまともに使えない。
そして、そんな都合のいい環境が、常に用意されているとは限らない。
ちゃんとテストしてちゃんと動くなら、例外投げる必要なんか無くなる。
そして、そんな都合のいい環境が、常に用意されているとは限らない。
ちゃんとテストしてちゃんと動くなら、例外投げる必要なんか無くなる。
全ての例外のcatchを書いて、そのcatchの中に全て同じ記述があるのとか勘弁
ちゃんと
↑
あいまい過ぎ。いつでもその基準を都合よく変えられる。
例外の話に限らず、常にこういう不誠実な物言いしているんだろうな。
↑
あいまい過ぎ。いつでもその基準を都合よく変えられる。
例外の話に限らず、常にこういう不誠実な物言いしているんだろうな。
今日は想定内の例外を復旧してるのにerrorでスタックトレースまで吐いてる馬鹿がいてがっかりした
紛らわしい
紛らわしい
>>728
純粋な疑問なんだけど、そういう気がした理由が知りたい
俺はむしろ複雑になるほど、チェック漏れなんかの影響が思いもよらないとこで出る可能性の高い
続行不可な異常系を戻り値にまとめるやり方は、やりたくないけどなぁ
純粋な疑問なんだけど、そういう気がした理由が知りたい
俺はむしろ複雑になるほど、チェック漏れなんかの影響が思いもよらないとこで出る可能性の高い
続行不可な異常系を戻り値にまとめるやり方は、やりたくないけどなぁ
無駄に長いcatch句が必要になるのは
try句が無駄に糞長いせいじゃないの
そもそも、一つのメソッドがそんなに複数のExceptionを投げるのは設計がよくないでしょ
後続となる処理が明確にきまってんなら、もっと小さな、各々の例外の発生元でcatchして
ログはくなりして、共通の例外でラップしてから再Throwすべきなんじゃね？
なんつか、殆どの問題って例外がーっていうか、プログラム設計が悪いよね
try句が無駄に糞長いせいじゃないの
そもそも、一つのメソッドがそんなに複数のExceptionを投げるのは設計がよくないでしょ
後続となる処理が明確にきまってんなら、もっと小さな、各々の例外の発生元でcatchして
ログはくなりして、共通の例外でラップしてから再Throwすべきなんじゃね？
なんつか、殆どの問題って例外がーっていうか、プログラム設計が悪いよね
よし、勝った。
やはり例外は使えない
ずっとみてるが、例外派からこの話題がないのがおかしい
fがg,gがh,hがiを呼んでいるケースでiが例外を投げ、fがキャッチする
これを例外で書くのと戻り値で書くのとでは作業量が全然違う
例外を使う場合、g,hは何も修正がいらないか、throws節を付ける程度で済む(言語による)
戻り値だとそうはいかない
fがg,gがh,hがiを呼んでいるケースでiが例外を投げ、fがキャッチする
これを例外で書くのと戻り値で書くのとでは作業量が全然違う
例外を使う場合、g,hは何も修正がいらないか、throws節を付ける程度で済む(言語による)
戻り値だとそうはいかない
既出では？
それ以前にiの仕様変更がfまで波及する作りに疑問を感じた
独自の例外クラスで仕様変更して投げたら同じ事が言えるわけだが。
既出だったのか、すまん
>>738 戻り値だって同じな上、修正量は戻り値のほうが多い
>>738 戻り値だって同じな上、修正量は戻り値のほうが多い
>>701
どこがー、とかを知る必要はないよ。そもそも処理を分岐するために判断とかいらない
発生する可能性があることがわかってんなら、>>689みたいにハナから限定してしまえばいいんだって
別に、メソッドの最初にtry最後にcatch/finnalyしないといけないワケじゃないよ
catchするのは基本的に発生することが確実にわかってて、
どう振舞うかが決まってる例外だけで、それ以外は基本的に無視
catchしたあと後続処理を続行できない場合は、共通の例外なんかでラップして再throwすればいい
無視された例外や共通の例外については、大元のほうを手がける人だけが処理すればいいのよ
ここなら確実にやり直せる(or終了できる)って場所でキャッチして、リトライなり落とすなりすればいい
例外は、あくまでも呼び出した先の処理が解決できなかった問題ってだけで、
呼び出し元が解決策を持ってるなら、すぐに処理するべきなのよ
処理できるのにそこで処理しなかったら、大元んとこで捕まえてログなり吐くように作るわけから、
バグがあることが一目瞭然だぜー、って仕組みってだけで、難しいことじゃないよ
どこがー、とかを知る必要はないよ。そもそも処理を分岐するために判断とかいらない
発生する可能性があることがわかってんなら、>>689みたいにハナから限定してしまえばいいんだって
別に、メソッドの最初にtry最後にcatch/finnalyしないといけないワケじゃないよ
catchするのは基本的に発生することが確実にわかってて、
どう振舞うかが決まってる例外だけで、それ以外は基本的に無視
catchしたあと後続処理を続行できない場合は、共通の例外なんかでラップして再throwすればいい
無視された例外や共通の例外については、大元のほうを手がける人だけが処理すればいいのよ
ここなら確実にやり直せる(or終了できる)って場所でキャッチして、リトライなり落とすなりすればいい
例外は、あくまでも呼び出した先の処理が解決できなかった問題ってだけで、
呼び出し元が解決策を持ってるなら、すぐに処理するべきなのよ
処理できるのにそこで処理しなかったら、大元んとこで捕まえてログなり吐くように作るわけから、
バグがあることが一目瞭然だぜー、って仕組みってだけで、難しいことじゃないよ
>ここなら確実にやり直せる(or終了できる)って場所でキャッチして、リトライなり落とすなりすればいい
try-catch ブロックのカタマリだらけになるだろ
↓
じゃあ、分けろ
↓
関数とかで分けたら、結局その中で発生した例外は、その中でのみ処理される
↓
関数からは、実行の成否が区別できる戻り値が帰ってくる
↓
戻り値見て、失敗だったらもう一回例外投げろ ← ？？？？？
もうね、ア ホ かと・・・ バ カ かと・・・
try-catch ブロックのカタマリだらけになるだろ
↓
じゃあ、分けろ
↓
関数とかで分けたら、結局その中で発生した例外は、その中でのみ処理される
↓
関数からは、実行の成否が区別できる戻り値が帰ってくる
↓
戻り値見て、失敗だったらもう一回例外投げろ ← ？？？？？
もうね、ア ホ かと・・・ バ カ かと・・・
>>736
f,g,h,iを一体で設計するする場合なら例外でもいいと思うよ。
private関数から呼ばれる関数群のように、
iが呼ばれるのはhからだけと決まっていて、hが呼ばれるのはgからだけと決まっていて、
gが呼ばれるのはfからだけと決まっている場合は f,g,h,iのことだけ考えて実装すればいいしね。
f,g,h,iを一体で設計するする場合なら例外でもいいと思うよ。
private関数から呼ばれる関数群のように、
iが呼ばれるのはhからだけと決まっていて、hが呼ばれるのはgからだけと決まっていて、
gが呼ばれるのはfからだけと決まっている場合は f,g,h,iのことだけ考えて実装すればいいしね。
呼び出し元が何であるかなんてのは考慮する必要はないでしょ
決まった条件のときにこういった例外が発生するってことだけがわかっていればいい
その例外が発生したときにどう振舞うかは、呼び出した側の責務なんだし
>>742
後続の処理は行えないけど、想定している状況の場合は、
その復旧が行える処理がキャッチできるような共通の例外でラップして投げなおすんだよ
たとえば、ユーザーの入力した値がエラーだった場合を想定してみ
入力値は複数の種類があるけど、入力エラーとして再入力を促す処理は1つじゃん
値の検証で、日付入力値が正しくない例外、数値に文字が入っていた例外、みたいな想定内の例外を投げる
その例外は呼び出したところがそれぞれキャッチし、入力エラーの例外をつくって再スロー、
今度は、再入力を促せる処理がキャッチし復旧(再入力を促す)する
現実的には、パターンマッチやらisHogeTypeやらtryParseやらで真偽が判定できるような
値の検証で、例外投げるような処理を作るこたないだろうが、
たとえだからそこらへんは適当に脳内変換しておくれ
もちろん、プログラムなんてどんな風にでも書けるわけで、戻り値だけでも実現できるし、
スパゲティを作ることだって出来る。ただ規模がでかくなると依存関係の高まる戻り値よりはマシな形にはなるよ
決まった条件のときにこういった例外が発生するってことだけがわかっていればいい
その例外が発生したときにどう振舞うかは、呼び出した側の責務なんだし
>>742
後続の処理は行えないけど、想定している状況の場合は、
その復旧が行える処理がキャッチできるような共通の例外でラップして投げなおすんだよ
たとえば、ユーザーの入力した値がエラーだった場合を想定してみ
入力値は複数の種類があるけど、入力エラーとして再入力を促す処理は1つじゃん
値の検証で、日付入力値が正しくない例外、数値に文字が入っていた例外、みたいな想定内の例外を投げる
その例外は呼び出したところがそれぞれキャッチし、入力エラーの例外をつくって再スロー、
今度は、再入力を促せる処理がキャッチし復旧(再入力を促す)する
現実的には、パターンマッチやらisHogeTypeやらtryParseやらで真偽が判定できるような
値の検証で、例外投げるような処理を作るこたないだろうが、
たとえだからそこらへんは適当に脳内変換しておくれ
もちろん、プログラムなんてどんな風にでも書けるわけで、戻り値だけでも実現できるし、
スパゲティを作ることだって出来る。ただ規模がでかくなると依存関係の高まる戻り値よりはマシな形にはなるよ
GoToと似たようなもんだよね。
飛び先を指定するんじゃなくて、処理できる奴が捕まえるっていう逆の形だけれど。
それに、正しく使えば便利なのに、正しく使えない奴が多いから使用を制限されやすいってあたりもｗ
飛び先を指定するんじゃなくて、処理できる奴が捕まえるっていう逆の形だけれど。
それに、正しく使えば便利なのに、正しく使えない奴が多いから使用を制限されやすいってあたりもｗ
>>743
f が知ってるのは g を呼んだら 自分が処理できる例外が発生する可能性があることだけ
そしてその例外が発生した場合には、想定された復旧を行う役目がある
依存してるものは、g とその処理する例外だけ
g や h が知ってるのは、 g なら h 、h なら i を呼んだら、決められた例外が発生することだけ
しかしその例外は自分が処理できる例外ではないから、発生した例外は無視する
ただ、呼び出した処理が例外を投げ、それを無視することは事前に分かってる内容だから
検査例外がなければドキュメントとして残すだけでOK
誰から呼ばれたかなんてのは知らないし知る必要もない
i は呼ばれた場合に何かしら自分の処理が完遂できなくなった場合に、例外を発生する
もちろんこっちだって、誰に呼ばれたかなんてのは知らないし知る必要もない
設計の呼称はマチマチだから語弊の元だしあんまり話題にしたくないけど、
一般的にいう詳細設計とか内部設計的なレベルでは f サービスとして設計されてる一体のものだとしても、
プログラム設計のレベルでは、二つ飛ばした先の処理や、呼び出し元には依存はしてないよ
f が知ってるのは g を呼んだら 自分が処理できる例外が発生する可能性があることだけ
そしてその例外が発生した場合には、想定された復旧を行う役目がある
依存してるものは、g とその処理する例外だけ
g や h が知ってるのは、 g なら h 、h なら i を呼んだら、決められた例外が発生することだけ
しかしその例外は自分が処理できる例外ではないから、発生した例外は無視する
ただ、呼び出した処理が例外を投げ、それを無視することは事前に分かってる内容だから
検査例外がなければドキュメントとして残すだけでOK
誰から呼ばれたかなんてのは知らないし知る必要もない
i は呼ばれた場合に何かしら自分の処理が完遂できなくなった場合に、例外を発生する
もちろんこっちだって、誰に呼ばれたかなんてのは知らないし知る必要もない
設計の呼称はマチマチだから語弊の元だしあんまり話題にしたくないけど、
一般的にいう詳細設計とか内部設計的なレベルでは f サービスとして設計されてる一体のものだとしても、
プログラム設計のレベルでは、二つ飛ばした先の処理や、呼び出し元には依存はしてないよ
>>746
いつもの見えない敵と戦う人ですか？
いつもの見えない敵と戦う人ですか？
ところで、イベントプロシージャで独自の例外投げたら、誰がキャッチしてくれるの？
勝利宣言、釣り宣言、例外厨認定、一行レス。
このあたりはほぼ同じ人でしょｗ
このあたりはほぼ同じ人でしょｗ
知ったかぶりの人も、同じ人でしょｗ
例外の批判()でちょいちょい独自の例外がー、とか言って馬鹿いるけど
そりゃ例外がどうのじゃなくて、設計とレイガイガーって言ってる奴が頭悪いだけだろ
そりゃ例外がどうのじゃなくて、設計とレイガイガーって言ってる奴が頭悪いだけだろ
またレイガイガーが現れたのか
答えられないんですね。わかります。
レイガイガー「くっ、次から次へと例外が沸いてきやがる」
モドリッチ伯爵「なさけないぞレイガイガー！それでも私がライバルと認めた男か！」
レイガイガー「お、お前は！？ふふふ……まさかお前に励まされる日が来ようとはな」
モドリッチ伯爵「勘違いするな。お前を倒すのはこの俺だ。そんなバグに負けるなど許さんからな」
モドリッチ伯爵「なさけないぞレイガイガー！それでも私がライバルと認めた男か！」
レイガイガー「お、お前は！？ふふふ……まさかお前に励まされる日が来ようとはな」
モドリッチ伯爵「勘違いするな。お前を倒すのはこの俺だ。そんなバグに負けるなど許さんからな」
それ書くのに、オマエの人生何分消費したｗ
757 ：仕様書無しさん：2011/02/16(水) 21:19:32
戻り値の人って、ロールバック処理知ってるのかな？
いきなり遥か遠方にまで戻るか？
例外は常に親関数にしか戻らない。
また、前の行に飛んだりしない。
だからGOTOなんかとはぜんぜん違うものだよ。
たまに例外だと一気にmain（もしくは呼出履歴のずっと上）のところまで
飛ぶと思っている人がいるけどそれは違う。
親関数に戻って、そこから親関数に戻ってと
呼出履歴を一つずつ逆にたどっているだけ
また、前の行に飛んだりしない。
だからGOTOなんかとはぜんぜん違うものだよ。
たまに例外だと一気にmain（もしくは呼出履歴のずっと上）のところまで
飛ぶと思っている人がいるけどそれは違う。
親関数に戻って、そこから親関数に戻ってと
呼出履歴を一つずつ逆にたどっているだけ
>>749
> ところで、イベントプロシージャで独自の例外投げたら、誰がキャッチしてくれるの？
自分で試してみればいいじゃん。
そもそもなんのイベントプロシージャなのか。
イベントプロシージャというものが存在する言語（フレームワーク）を
使っているのなら、すぐに試して分かると思うが。
> ところで、イベントプロシージャで独自の例外投げたら、誰がキャッチしてくれるの？
自分で試してみればいいじゃん。
そもそもなんのイベントプロシージャなのか。
イベントプロシージャというものが存在する言語（フレームワーク）を
使っているのなら、すぐに試して分かると思うが。
>だからGOTOなんかとはぜんぜん違うものだよ。
知っとるわ
知っとるわ
設計と改修のコストがあがりそうだね
>>761
> 戻り値方式は、そもそも異常系を分離できないので設計が異なる
「設計が異なる」と言って満足するなよｗ
設計が異なるのは当たり前の話で、
その異なる設計の場合はどうする？ってことを
言うべきじゃねーの？
> 戻り値方式は、そもそも異常系を分離できないので設計が異なる
「設計が異なる」と言って満足するなよｗ
設計が異なるのは当たり前の話で、
その異なる設計の場合はどうする？ってことを
言うべきじゃねーの？
順繰りに戻って行くのなら、別に遠投目当ての仕組み使わなくてもいいじゃん。
例外嫌いは基本的に異常系を考慮しない設計が大好きな人が殆どだから、
実際問題コストはそんなにかからないよ
うまいこと無視した例外が表向き変な動作をしてなければテストも通るし、事なきを得る
改修は残業
>>765
そういうきまったものを毎回書き起こす必要があるってのが無駄だから
言語側でカバーしてるんでしょ
実際問題コストはそんなにかからないよ
うまいこと無視した例外が表向き変な動作をしてなければテストも通るし、事なきを得る
改修は残業
>>765
そういうきまったものを毎回書き起こす必要があるってのが無駄だから
言語側でカバーしてるんでしょ
例外使わないと厄介な事になる事例って、あるか？
>>767
途中で何も書かなければ、結果的に遠投になるがｗ
途中で何も書かなければ、結果的に遠投になるがｗ
バケツリレーする羽目になるよかはマシだわな
異常系をちゃんと考慮する必要があるなら、例外使わないとかありえないわなぁ
異常系もちゃんと考慮するのは当たり前って意見はあると思うけど、
ほら、コスト的な意味とかでさ…ね…
異常系をちゃんと考慮する必要があるなら、例外使わないとかありえないわなぁ
異常系もちゃんと考慮するのは当たり前って意見はあると思うけど、
ほら、コスト的な意味とかでさ…ね…
例外そのものは有用な場面もあるんだが、
例外を制御構造の代わりに使おうという間違った使い方してる奴が現れるからなー。
例外を制御構造の代わりに使おうという間違った使い方してる奴が現れるからなー。
>>770
これがGOTOだと、間で止めようと思っても無理だろ？
順繰りに戻って行くというのは、
間で止めようと思ったら止められる。
戻り先は綱に呼び出し元関数に限られ
GOTOのように全く無関係のコードに飛んだりはしない。
だから遠くに投げるのとは根本的に違いがある。
これがGOTOだと、間で止めようと思っても無理だろ？
順繰りに戻って行くというのは、
間で止めようと思ったら止められる。
戻り先は綱に呼び出し元関数に限られ
GOTOのように全く無関係のコードに飛んだりはしない。
だから遠くに投げるのとは根本的に違いがある。
例外と戻り値の話になってるのに、なんでそこでいきなり goto の話を
持ち出してくるんだろ。詭弁のガイドラインに抵触してるよな。
持ち出してくるんだろ。詭弁のガイドラインに抵触してるよな。
メソッドが処理できなければ例外発生、異常系
復旧し正常に戻せれば戻して続行、無理なら諦めて異常ルートを進む
正常と異常が明確に分けれ、第三者がみても説明しなくても意図がわかる
ほとんどの言語で、同じようなコーディングが出来るってとこもメリットでしょ
頻度が高く、どうせ復旧されるのが分かりきってるものにまで例外投げろとかは言わんが
基本的に、問題がない正常な値だけを戻してくれるほうが分かりやすい
復旧し正常に戻せれば戻して続行、無理なら諦めて異常ルートを進む
正常と異常が明確に分けれ、第三者がみても説明しなくても意図がわかる
ほとんどの言語で、同じようなコーディングが出来るってとこもメリットでしょ
頻度が高く、どうせ復旧されるのが分かりきってるものにまで例外投げろとかは言わんが
基本的に、問題がない正常な値だけを戻してくれるほうが分かりやすい
例外を遠くへ飛ぶものだと勘違いしているやつがいるからだよ。
例外が遠くへ飛ぶように見える＝gotoに似てる。
gotoは悪、故に例外も悪。
まあ、これは詭弁で間違いないが。
例外は遠くへは飛ばない。常に上の関数に戻るだけ。
例外が遠くへ飛ぶように見える＝gotoに似てる。
gotoは悪、故に例外も悪。
まあ、これは詭弁で間違いないが。
例外は遠くへは飛ばない。常に上の関数に戻るだけ。
お前らの言う異常系は
正常系、準正常系、異常系
の分類で言ってどれなんだ？
なんか各々違う言葉をしゃべってそうで
正常系、準正常系、異常系
の分類で言ってどれなんだ？
なんか各々違う言葉をしゃべってそうで
例外使っていれば、関数の戻り値の型の制約を受けないってのもいい。
関数の戻り値がboolだろうがintだろうが、
それとは無関係に、例外オブジェクトを返すことができる。
関数の戻り値がboolだろうがintだろうが、
それとは無関係に、例外オブジェクトを返すことができる。
>>778
じゃあまずはお前が定義を言ってくれ
じゃあまずはお前が定義を言ってくれ
準正常系ってなんだ？
正常系、異常権の意味も、
外部だの内部だの基本だの詳細だのの意味も、
参加するプロジェクトの親とか、PLやらPMの今までの経験とかで
まったく違う意味になったりするから、なんともだわｗ
このあたりもう少し明確な線引きが欲しくなるわｗ
外部だの内部だの基本だの詳細だのの意味も、
参加するプロジェクトの親とか、PLやらPMの今までの経験とかで
まったく違う意味になったりするから、なんともだわｗ
このあたりもう少し明確な線引きが欲しくなるわｗ
>>776
そもそも、正常な値かどうかは呼び出し元が決めることだからな。
getHoge();で hogeが取れない場合も正常系の処理を進めないといけない場合などに
例外でhogeが取れない事を通知されると、例外パスを通るんだけど正常系という、
第三者的に分かりにくい構造にしないといけない。
そもそも、正常な値かどうかは呼び出し元が決めることだからな。
getHoge();で hogeが取れない場合も正常系の処理を進めないといけない場合などに
例外でhogeが取れない事を通知されると、例外パスを通るんだけど正常系という、
第三者的に分かりにくい構造にしないといけない。
>>778
関数の異常系と、システム全体の異常系ってのは別の話で、
たとえばサーバーに接続できないエラーってのは、
サーバーに接続する関数からしてみれば異常系だが、
システム全体からすれば、ただのURL入力エラーなんだよ。
で例外を出すかどうかの基準というのは、システム全体の
異常系ではなく、関数の異常系の場合。
なぜなら関数はシステム全体ではない（システムの一部）だから。
だからシステム全体を見た場合の異常かどうかってのは考えずに
関数が受け持った処理ができれば正常、できなければ異常。
これでよい。関数の名前がその関数がやる処理を意味しているから、
関数名さえわかれば、何を例外とすべきかは自ずと決まる。
関数の異常系と、システム全体の異常系ってのは別の話で、
たとえばサーバーに接続できないエラーってのは、
サーバーに接続する関数からしてみれば異常系だが、
システム全体からすれば、ただのURL入力エラーなんだよ。
で例外を出すかどうかの基準というのは、システム全体の
異常系ではなく、関数の異常系の場合。
なぜなら関数はシステム全体ではない（システムの一部）だから。
だからシステム全体を見た場合の異常かどうかってのは考えずに
関数が受け持った処理ができれば正常、できなければ異常。
これでよい。関数の名前がその関数がやる処理を意味しているから、
関数名さえわかれば、何を例外とすべきかは自ずと決まる。
>例外が遠くへ飛ぶように見える＝gotoに似てる
誰もそんな事言ってない。 お前が勝手にそう解釈してるだけ。
誰もそんな事言ってない。 お前が勝手にそう解釈してるだけ。
正常=プログラム本来の目的の処理を実行できる。
異常=プログラム本来の目的を実行できない。
異常=プログラム本来の目的を実行できない。
getHoge()だったら、Hogeをゲットできれば正常で
Hogeをゲット出来なければ異常（例外送出）ということになる。
関数に取っての異常系かどうかを見るべきで、
呼び出し元（システム全体）のことを考えてはいけない。
Hogeをゲット出来なければ異常（例外送出）ということになる。
関数に取っての異常系かどうかを見るべきで、
呼び出し元（システム全体）のことを考えてはいけない。
例外を出すか出さないかの判断で、
システム全体を見てはいけないというのは、
その関数がライブラリだったら？と考えることでも
理解できると思う。
このライブラリは、どのシステムで使われるかはわからないのだから、
システム全体（呼び出し元）のことを考えて例外にするかどうかを
判断するのは間違っているということがわかるだろう。
システム全体を見てはいけないというのは、
その関数がライブラリだったら？と考えることでも
理解できると思う。
このライブラリは、どのシステムで使われるかはわからないのだから、
システム全体（呼び出し元）のことを考えて例外にするかどうかを
判断するのは間違っているということがわかるだろう。
>>789
理由書いてないよ。
理由書いてないよ。
>>791
処理が煩雑になるから。
処理が煩雑になるから。
>>792
ならないんだが？
ならないんだが？
俺も昔は関数名をつけるのに悩んでいた時期があるよ。
そういうレベルの人は何を例外にするかわかりにくいんだろうな。
関数名の最初は動詞。それができれば正常、
できなければ異常。簡単な話だよ。
そういうレベルの人は何を例外にするかわかりにくいんだろうな。
関数名の最初は動詞。それができれば正常、
できなければ異常。簡単な話だよ。
>>784
hogeが取れない場合にどうするかは呼び出し元が決めることで
hogeが取れない場合にhogeとは異なる失敗を示す値を返されたら
それを判定する処理が必要になるだろ。呼び出し元では空文字列が欲しいから
空文字列を返す、ってのは呼び出し元に依存した設計じゃね
hogeを返すことが生業のgetHoge()くんがhogeを返せないのに職務を全うした顔で
違うもの返すのは、お行儀が悪いやりかた、って事だよ
行儀が悪くても死ぬわけじゃないし、所詮行儀の話でしかないけどな
hogeが取れない場合にどうするかは呼び出し元が決めることで
hogeが取れない場合にhogeとは異なる失敗を示す値を返されたら
それを判定する処理が必要になるだろ。呼び出し元では空文字列が欲しいから
空文字列を返す、ってのは呼び出し元に依存した設計じゃね
hogeを返すことが生業のgetHoge()くんがhogeを返せないのに職務を全うした顔で
違うもの返すのは、お行儀が悪いやりかた、って事だよ
行儀が悪くても死ぬわけじゃないし、所詮行儀の話でしかないけどな
ご高説、かっこいーｗ
関数名の最初は動詞。それができれば正常(ｷﾘｯ
いくらなんでも痛すぎる・・・
いくらなんでも痛すぎる・・・
>>792
理解が追いつかないからの間違いだな
理解が追いつかないからの間違いだな
言ってることはそんなに間違えてないと思うんだが、
なんか>>790に猛烈なおじゃば臭を感じる。
なんか>>790に猛烈なおじゃば臭を感じる。
>>800
晒されてる理由が分からん所が、更に痛いんだがｗ
晒されてる理由が分からん所が、更に痛いんだがｗ
>>790の言ってることは、別に間違ってないけどね。 結合度弱くなるし。
>>801
キャッチしたら復旧処理か再スローのどっちかでしょ
復旧しななら続行できるから異常じゃなくなるでしょ
再スローしたら、復旧してない
システム共通の例外にまで復旧して、投げなおすってパターンもあるだろうけどな
>>802
よく読んで
キャッチしたら復旧処理か再スローのどっちかでしょ
復旧しななら続行できるから異常じゃなくなるでしょ
再スローしたら、復旧してない
システム共通の例外にまで復旧して、投げなおすってパターンもあるだろうけどな
>>802
よく読んで
このあたりの認識って、別にJavaに限ったことじゃなくね
レトロな頭してる人には理解してもらえないこともよくあるけど
レトロな頭してる人には理解してもらえないこともよくあるけど
お前のプログラムではそうなのかもしれないが
> キャッチしたら復旧処理か再スローのどっちかでしょ
この二つに限定してしまうのはどうかと。
> キャッチしたら復旧処理か再スローのどっちかでしょ
この二つに限定してしまうのはどうかと。
>>810
何が言いたいの？
何が言いたいの？
>>809
他に何か出来るよ？
ログ吐くとか終了するとかそういう話されるとアレだけど、流石にんな話はしないでしょｗ
自分が復旧できない例外なら投げるしかないし、
そもそもハナから復旧ができないものは捕まえちゃだめだ
捕まえるのは復旧方法を知ってるからなわけで、それ以外に何をしたいの？
>>810
金のなるJavaで増えた職業PGが全般的に酷いのはすごくわかるけど、
例外の基本的な扱い方自体はとくに言語の壁はなくね
このあたりの認識 = 例外の扱い方のお作法、ってカンジの意味で使ったけど、
そのお作法の認識、って感じにも読み取れちゃうから不明瞭だねｽﾏﾝｺ
他に何か出来るよ？
ログ吐くとか終了するとかそういう話されるとアレだけど、流石にんな話はしないでしょｗ
自分が復旧できない例外なら投げるしかないし、
そもそもハナから復旧ができないものは捕まえちゃだめだ
捕まえるのは復旧方法を知ってるからなわけで、それ以外に何をしたいの？
>>810
金のなるJavaで増えた職業PGが全般的に酷いのはすごくわかるけど、
例外の基本的な扱い方自体はとくに言語の壁はなくね
このあたりの認識 = 例外の扱い方のお作法、ってカンジの意味で使ったけど、
そのお作法の認識、って感じにも読み取れちゃうから不明瞭だねｽﾏﾝｺ
こいつ、猛烈にうさんくせーな
hogeが取得出来なければ、引数で渡されたデフォルト値を返す方法もあし
そういう使い方しかしないなら、暗黙にデフォルト値を返す設計もありうる。
これは別に、呼出し元に依存した設計じゃないよ。
そういう使い方しかしないなら、暗黙にデフォルト値を返す設計もありうる。
これは別に、呼出し元に依存した設計じゃないよ。
>>812
javaだけは、チェック例外という糞仕様があるので、作法は違ってたり。
javaだけは、チェック例外という糞仕様があるので、作法は違ってたり。
>>814
完全な正常系の流れなのに「復旧」は無いわー。
完全な正常系の流れなのに「復旧」は無いわー。
達人は、例外を出すような事象に遭遇しない。 護身、完成。 これ。
>>815
いや、返し方とか暗黙のデフォルトとか、そういう事じゃなくてさ
それに、それだと場合によっては hoge じゃないものも返しますーなメソッドになっちゃうので
getHoge() って名前が相応しくないことになるっしょ
getHoge() の負うべき責務は、hogeをgetすることだけなので、
それ以外はgetHoge()としては正常ではない。例外投げるのであとは好きにして、ってことでしょ
受け取った側がそれを復旧するか無視するかは自由
仕様上hogeがgetできないことを想定しないってなってるなら無視してもいいわけ
(つっても、こういうのは基本的に仕様のバグだから修正して貰うべきだったりするけれど)
>>816
検査例外もそこそこ便利だとは思うんだけどなー
どういう例外を処理する必要があるか明確になってたら、
知らんメソッドでも型名だけみてソラでコーディングできたりするし、考慮漏れの防止にもなる
復旧が上位でしかできない例外が下位に追加されると修正がめんどくせーし、
throws Exception 一つで崩壊するけどｗ
いや、返し方とか暗黙のデフォルトとか、そういう事じゃなくてさ
それに、それだと場合によっては hoge じゃないものも返しますーなメソッドになっちゃうので
getHoge() って名前が相応しくないことになるっしょ
getHoge() の負うべき責務は、hogeをgetすることだけなので、
それ以外はgetHoge()としては正常ではない。例外投げるのであとは好きにして、ってことでしょ
受け取った側がそれを復旧するか無視するかは自由
仕様上hogeがgetできないことを想定しないってなってるなら無視してもいいわけ
(つっても、こういうのは基本的に仕様のバグだから修正して貰うべきだったりするけれど)
>>816
検査例外もそこそこ便利だとは思うんだけどなー
どういう例外を処理する必要があるか明確になってたら、
知らんメソッドでも型名だけみてソラでコーディングできたりするし、考慮漏れの防止にもなる
復旧が上位でしかできない例外が下位に追加されると修正がめんどくせーし、
throws Exception 一つで崩壊するけどｗ
検査例外を
> 考慮漏れの防止にもなる
と思ってたらハマるんだよなー
> 考慮漏れの防止にもなる
と思ってたらハマるんだよなー
正しく使われること自体が稀な検査例外なんて、
一理なしとはでは言わんが、百害も二百害もあるわなｗ
一理なしとはでは言わんが、百害も二百害もあるわなｗ
>>820
検査例外は、メリットよりデメリットの方が上回ってるからなあ。
本来なら扱わなくてもいいものを、扱う事を強制する訳だし。(場合によっては大量に)
たぶん、例外を一つにまとめて再throwする、って言う人がいるのも、検査例外のせいだろうし。
検査例外は、メリットよりデメリットの方が上回ってるからなあ。
本来なら扱わなくてもいいものを、扱う事を強制する訳だし。(場合によっては大量に)
たぶん、例外を一つにまとめて再throwする、って言う人がいるのも、検査例外のせいだろうし。
関数はその使われ方を意識してはいけないのが原則なのに、
「必ずチェックしろ」と使われ方を意識することになる
強制する検査例外は原則から外れているんだよね。
投げる例外を明確にするという点ではよかったが、
必ずチェックするという決まりは不要だった。
重要なのは投げる例外が何かではなく、それ以外の例外(RuntimeExceptionのサブクラスは除く）は
投げないという事だろうな。それ以外の例外は投げないということがわかれば、
投げられるはずがない例外をcatchするというコードを書いてしまったとき
このcatchは不要ですって警告を出せるしね。
「必ずチェックしろ」と使われ方を意識することになる
強制する検査例外は原則から外れているんだよね。
投げる例外を明確にするという点ではよかったが、
必ずチェックするという決まりは不要だった。
重要なのは投げる例外が何かではなく、それ以外の例外(RuntimeExceptionのサブクラスは除く）は
投げないという事だろうな。それ以外の例外は投げないということがわかれば、
投げられるはずがない例外をcatchするというコードを書いてしまったとき
このcatchは不要ですって警告を出せるしね。
>>820
俺がいいたいのは、そういう事なんだけどなぁ。
getHoge()という名前で、失敗時に適切な回復してくれるような
処理はめずらしくないし、名前が間違っているとも思わない。
失敗したからといって、杓子定規に例外を投げるのが常に正しいとは限らんと思うよ。
俺がいいたいのは、そういう事なんだけどなぁ。
getHoge()という名前で、失敗時に適切な回復してくれるような
処理はめずらしくないし、名前が間違っているとも思わない。
失敗したからといって、杓子定規に例外を投げるのが常に正しいとは限らんと思うよ。
>>824
複数の例外が一つのメソッドからわんさかあがってくるような作りになってたり、
一つのtry句に対してたくさんのcatchが必要になるものは、
プログラムの設計のほうにも問題ありそうだけどなｗ
>>825
んだなぁ。まぁ今更語るような事ではないのは承知してるけどｗ
まぁ警告なんて無視しまくる人が多いし、たとえ強制じゃなかったとしても、
形だけの意味のないものになっていたかもしれないけれど…
複数の例外が一つのメソッドからわんさかあがってくるような作りになってたり、
一つのtry句に対してたくさんのcatchが必要になるものは、
プログラムの設計のほうにも問題ありそうだけどなｗ
>>825
んだなぁ。まぁ今更語るような事ではないのは承知してるけどｗ
まぁ警告なんて無視しまくる人が多いし、たとえ強制じゃなかったとしても、
形だけの意味のないものになっていたかもしれないけれど…
>>825
投げる例外を限定出来る、という機能はC++に搭載されているけど、
そもそも、扱わない例外は、単純に無視すればいいだけなので、実は意味がないという。
あと、処理しなくてもいい例外をcatchしているのを発見しやすい、っていうけど、
わざわざそんなコード書くやつはおらんやろー。
投げる例外を限定出来る、という機能はC++に搭載されているけど、
そもそも、扱わない例外は、単純に無視すればいいだけなので、実は意味がないという。
あと、処理しなくてもいい例外をcatchしているのを発見しやすい、っていうけど、
わざわざそんなコード書くやつはおらんやろー。
>>826
お作法的には例外を投げるべき、って事よ
それがお作法としては正しいってだけで、システムで使われるものとして正しいかはモノによる
事前にチェックが可能だったり、頻繁にhogeが取れないケースがあるなら、都度例外投げるのは好ましくねーしな
けど、そういう話をしてるわけじゃないっしょ、ってこと
あと例外で扱う場合のメリットとして、こういうのもあると思う
getHoge() の仕様が、取得できなかった場合に null を返すもんだとする
getHoge() を使うのが、取得結果の hoge をチェックせずに、hogeのメソッドをコールしちゃう、
正常系しか見てませんなせっかちちゃんが担当だったりした場合、hoge取れなくて、ぬるぽ
こういう不具合って結構よくあるじゃん
このときに出るスタックトレースは、ぬるぽの場所であって、元凶の取得失敗は出てこないんだよね
この程度なら原因特定は別に困難じゃないけど、複雑なものになってくると、特定がめんどくさくなってくる
そういう風に考えると、チェック漏れる可能性のあるやり方よりは、
漏れてたらその漏れた場所が明確に分かる方がいいんじゃないかなって考えちゃう
お作法的には例外を投げるべき、って事よ
それがお作法としては正しいってだけで、システムで使われるものとして正しいかはモノによる
事前にチェックが可能だったり、頻繁にhogeが取れないケースがあるなら、都度例外投げるのは好ましくねーしな
けど、そういう話をしてるわけじゃないっしょ、ってこと
あと例外で扱う場合のメリットとして、こういうのもあると思う
getHoge() の仕様が、取得できなかった場合に null を返すもんだとする
getHoge() を使うのが、取得結果の hoge をチェックせずに、hogeのメソッドをコールしちゃう、
正常系しか見てませんなせっかちちゃんが担当だったりした場合、hoge取れなくて、ぬるぽ
こういう不具合って結構よくあるじゃん
このときに出るスタックトレースは、ぬるぽの場所であって、元凶の取得失敗は出てこないんだよね
この程度なら原因特定は別に困難じゃないけど、複雑なものになってくると、特定がめんどくさくなってくる
そういう風に考えると、チェック漏れる可能性のあるやり方よりは、
漏れてたらその漏れた場所が明確に分かる方がいいんじゃないかなって考えちゃう
>>828
何がくるかよく分かってないから catch (Exception e) ってやる奴は多いぞｗ
コードレビューとかちゃんとやってるとこなら、誰かが指摘してくれんだけれど
そういうのがおなざりになってる場所だと、いろいろギャグみたいなの出てくるし
何がくるかよく分かってないから catch (Exception e) ってやる奴は多いぞｗ
コードレビューとかちゃんとやってるとこなら、誰かが指摘してくれんだけれど
そういうのがおなざりになってる場所だと、いろいろギャグみたいなの出てくるし
そしてスレタイに繋がるのであった。
>>831
無視したら落ちたから。
無視したら落ちたから。
この処理は、829の言うお作法にのっとって例外投げてるけれど、
こっちの処理は、お行儀悪く、戻り値を格調して複数の意味がある値を返して失敗を通知してくる。
そういうのが混在しないように、多少回りくどいやりかたでも、
推奨されてるやり方で統一するってのは、それはそれで意味がある行為だと思う。
なぜなら、コーディングルールにおいては、例外を作る必要なんてないのだから。
こっちの処理は、お行儀悪く、戻り値を格調して複数の意味がある値を返して失敗を通知してくる。
そういうのが混在しないように、多少回りくどいやりかたでも、
推奨されてるやり方で統一するってのは、それはそれで意味がある行為だと思う。
なぜなら、コーディングルールにおいては、例外を作る必要なんてないのだから。
例外厨：ボクが一番うまく例外を使えるんだ！
>>826
> 俺がいいたいのは、そういう事なんだけどなぁ。
> getHoge()という名前で、失敗時に適切な回復してくれるような
> 処理はめずらしくないし、名前が間違っているとも思わない。
だから、エラーを返さない仕様の関数の話なんかしてないんだってば。
エラーを戻り値で返す関数と
エラーを例外で返す関数の話をしている。
> 俺がいいたいのは、そういう事なんだけどなぁ。
> getHoge()という名前で、失敗時に適切な回復してくれるような
> 処理はめずらしくないし、名前が間違っているとも思わない。
だから、エラーを返さない仕様の関数の話なんかしてないんだってば。
エラーを戻り値で返す関数と
エラーを例外で返す関数の話をしている。
表現の問題かもだけど、例外を無視するって凄い違和感ある。
下位層で例外を無視したら上位層はどんな例外が
上がって来るのか把握出来なくなるじゃん。
把握してない例外についてどれを処理すべきか
判断するのは無理じゃね？
コード上で無視してるように見えても、仕様上で無視したらダメだろ。
メソッドの仕様として「この例外はcatchしない」と書いてあれば
メソッドとしては、その例外は無視してない。
ちゃんとチェックされてる。
下位層で例外を無視したら上位層はどんな例外が
上がって来るのか把握出来なくなるじゃん。
把握してない例外についてどれを処理すべきか
判断するのは無理じゃね？
コード上で無視してるように見えても、仕様上で無視したらダメだろ。
メソッドの仕様として「この例外はcatchしない」と書いてあれば
メソッドとしては、その例外は無視してない。
ちゃんとチェックされてる。
> 把握してない例外についてどれを処理すべきか
> 判断するのは無理じゃね？
可能。
未知のエラーとして取り扱えばいい。
> 判断するのは無理じゃね？
可能。
未知のエラーとして取り扱えばいい。
ライブラリが投げた未知のエラーのうち
アプリが処理したいエラーはどれよ？
アプリが処理したいエラーはどれよ？
840 ：仕様書無しさん：2011/02/17(木) 12:39:12
とにかく、例外は、実装の作法が不自然だわ。
それに、どうせ順番に上層に伝わっていくんなら、関数呼出から
戻る為のオーバーヘッドが実行時間の大半を占めるだろうから、
大して時間も短縮出来ないだろ。
それに、どうせ順番に上層に伝わっていくんなら、関数呼出から
戻る為のオーバーヘッドが実行時間の大半を占めるだろうから、
大して時間も短縮出来ないだろ。
どうしても例外と戻り値の比較にしたいやつらがいるな。
エラー伝達に例外を使おうが、戻り値を使おうが本質的な違いはないんだけどな。
ところが、なまじっか言語の機構として例外処理システムが組込まれていると、
よく考えもせず「エラー即例外」というバカが表れはじめる。
中には、本気で「例外うぜー」という連中もいるかもしれないが、
その原因は、ほとんどがエラー処理がまともに出来ない例外バカのせい。
エラー伝達に例外を使おうが、戻り値を使おうが本質的な違いはないんだけどな。
ところが、なまじっか言語の機構として例外処理システムが組込まれていると、
よく考えもせず「エラー即例外」というバカが表れはじめる。
中には、本気で「例外うぜー」という連中もいるかもしれないが、
その原因は、ほとんどがエラー処理がまともに出来ない例外バカのせい。
原理主義者がバカなのは、どの分野でも同じ
そもそもそれをエラーなのか例外なのかを判断するのは呼び出し側であって
てめぇ（関数作成した奴）じゃねぇよって場面も多い気がする
てめぇ（関数作成した奴）じゃねぇよって場面も多い気がする
違うな。 例外起こす原因となった処理を実行した奴が判断するべき
だから、呼び出された側が判断するべき。
だから、呼び出された側が判断するべき。
845 ：仕様書無しさん：2011/02/17(木) 19:01:40
｀| __,.. -_‐ ニニﾆ ‐_- ､ _ l ,.-'ﾞ
〈.r '' ´ ｀ '' -={}
/:::!`ァ- ､..,,＿＿＿＿,,,.. -､,''ﾞｿ:::ﾍ
/:::::l ﾞ ,.r＝ ` ´ ｧ=-､ ` l::::_ｨ
〈ヽ| 'ﾞ ノ i 丶 l/,' |
. , ‐ 、 | 〉! l l | ﾘ 例外は、見なかったことにしよう
. ヽ. ヽ ヽ`| l _ ｋ/
. ヽ ヽ l｣ , ｀ ヽ l-ﾞ
ヽ. ', /￣〉 ﾍ ' ､ー――一ァ /
', '、, べ、 ｌ ヽ ヽニニニｼ /
ﾞ, ／ _ ヽ! lヽ -―- ／l
. У_. イ ヽ 〉 _,| ｀ ､ ／ l_
呼ばれた奴が出来なかったから、サジならぬ例外を投げてんだろ
どういう理由だったら投げるかは事前にわかってんだから、
その場合どう振舞いたいかを呼んだほうが実装するだけ
どういう理由だったら投げるかは事前にわかってんだから、
その場合どう振舞いたいかを呼んだほうが実装するだけ
話についていけないばかりか、下手なこといって層叩きされたお馬鹿さんが
悔し紛れに粘着してて、なんか可哀想な気分になってくるスレだなここは…。
悔し紛れに粘着してて、なんか可哀想な気分になってくるスレだなここは…。
少なくともファイル読み込みミスった程度で投げられてはたまったものではない
849 ：仕様書無しさん：2011/02/17(木) 19:15:07
>>848
同意
同意
>>848
:::::::::::/ ヽ::::::::::::
:::::::::::| ば じ き i::::::::::::
:::::::::::.ゝ か つ み ﾉ:::::::::::
:::::::::::/ だ に は ｲ:::::::::::::
::::: | な。 ﾞi ::::::
＼_ ,,-'
――--､..,ヽ__ ＿,,-''
:::::::,-‐､,‐､ヽ. )ノ ＿,,...-
:::::_|/ ｡|｡ヽ|-i､ ∠＿:::::::::
／. ` ' ● ' ﾆ ､ ,-､ヽ|:::::::::
ニ ＿_ｌ＿_＿ノ |・ | |, -､::
/￣ ＿ | i ﾟr ｰ' 6 |::
|(￣`' ）/ / ,.. i '-
`ー---―' / '（__ ） ヽ 、
====（ i）==::::／ ,/ﾆニニ
:/ ヽ:::i /;;;;;;;;;;;;;;;;
:::::::::::/ ヽ::::::::::::
:::::::::::| ば じ き i::::::::::::
:::::::::::.ゝ か つ み ﾉ:::::::::::
:::::::::::/ だ に は ｲ:::::::::::::
::::: | な。 ﾞi ::::::
＼_ ,,-'
――--､..,ヽ__ ＿,,-''
:::::::,-‐､,‐､ヽ. )ノ ＿,,...-
:::::_|/ ｡|｡ヽ|-i､ ∠＿:::::::::
／. ` ' ● ' ﾆ ､ ,-､ヽ|:::::::::
ニ ＿_ｌ＿_＿ノ |・ | |, -､::
/￣ ＿ | i ﾟr ｰ' 6 |::
|(￣`' ）/ / ,.. i '-
`ー---―' / '（__ ） ヽ 、
====（ i）==::::／ ,/ﾆニニ
:/ ヽ:::i /;;;;;;;;;;;;;;;;
ああっ、もうダメッ！
ぁあ…例外投げるっ、例外投げますうっ！！
ビッ、ブリュッ、ブリュブリュブリュゥゥゥーーーーーッッッ！！！
いやああああっっっ！！見ないで、お願いぃぃぃっっっ！！！
ブジュッ！ジャアアアアーーーーーーッッッ…ブシャッ！
ブババババババアアアアアアッッッッ！！！！
んはああーーーーっっっ！！！ウッ、ウンッ、例外ォォォッッ！！！
ムリムリイッッ！！ブチュブチュッッ、ミチミチミチィィッッ！！！
おおっ！例外ッ！！ウッ、ウンッ、例外ッッ！！！例外見てぇっ ああっ、もうダメッ！！はうあああーーーーっっっ！！！
ブリイッ！ブボッ！ブリブリブリィィィィッッッッ！！！！
いやぁぁっ！あたし、こんなにいっぱい例外投げてるゥゥッ！
ぶびびびびびびびぃぃぃぃぃぃぃっっっっ！！！！ボトボトボトォォッッ！！！
ぁあ…例外投げるっ、例外投げますうっ！！
ビッ、ブリュッ、ブリュブリュブリュゥゥゥーーーーーッッッ！！！
いやああああっっっ！！見ないで、お願いぃぃぃっっっ！！！
ブジュッ！ジャアアアアーーーーーーッッッ…ブシャッ！
ブババババババアアアアアアッッッッ！！！！
んはああーーーーっっっ！！！ウッ、ウンッ、例外ォォォッッ！！！
ムリムリイッッ！！ブチュブチュッッ、ミチミチミチィィッッ！！！
おおっ！例外ッ！！ウッ、ウンッ、例外ッッ！！！例外見てぇっ ああっ、もうダメッ！！はうあああーーーーっっっ！！！
ブリイッ！ブボッ！ブリブリブリィィィィッッッッ！！！！
いやぁぁっ！あたし、こんなにいっぱい例外投げてるゥゥッ！
ぶびびびびびびびぃぃぃぃぃぃぃっっっっ！！！！ボトボトボトォォッッ！！！
ぁあ…例外投げるっ、例外投げますうっ！！
ビッ、ブリュッ、ブリュブリュブリュゥゥゥーーーーーッッッ！！！
いやああああっっっ！！見ないで、お願いぃぃぃっっっ！！！
ブジュッ！ジャアアアアーーーーーーッッッ…ブシャッ！
ブババババババアアアアアアッッッッ！！！！
んはああーーーーっっっ！！！ウッ、ウンッ、例外ォォォッッ！
ぁあ…例外投げるっ、例外投げますうっ！！
ビッ、ブリュッ、ブリュブリュブリュゥゥゥーーーーーッッッ！！！
いやああああっっっ！！見ないで、お願いぃぃぃっっっ！！！
ブジュッ！ジャアアアアーーーーーーッッッ…ブシャッ！
ブババババババアアアアアアッッッッ！！！！
んはああーーーーっっっ！！！ウッ、ウンッ、例外ォォォッッ！！！
ムリムリイッッ！！ブチュブチュッッ、ミチミチミチィィッッ！！！
おおっ！例外ッ！！ウッ、ウンッ、例外ッッ！！！例外見てぇっ ああっ、もうダメッ！！はうあああーーーーっっっ！！！
ブリイッ！ブボッ！ブリブリブリィィィィッッッッ！！！！
いやぁぁっ！あたし、こんなにいっぱい例外投げてるゥゥッ！
ぶびびびびびびびぃぃぃぃぃぃぃっっっっ！！！！ボトボトボトォォッッ！！！
ぁあ…例外投げるっ、例外投げますうっ！！
ビッ、ブリュッ、ブリュブリュブリュゥゥゥーーーーーッッッ！！！
いやああああっっっ！！見ないで、お願いぃぃぃっっっ！！！
ブジュッ！ジャアアアアーーーーーーッッッ…ブシャッ！
ブババババババアアアアアアッッッッ！！！！
んはああーーーーっっっ！！！ウッ、ウンッ、例外ォォォッッ！！！
ムリムリイッッ！！ブチュブチュッッ、ミチミチミチィィッッ！！！
おおっ！例外ッ！！ウッ、ウンッ、例外ッッ！！！例外見てぇっ ああっ、もうダメッ！！はうあああーーーーっっっ！！！
ブリイッ！ブボッ！ブリブリブリィィィィッッッッ！！！！
いやぁぁっ！あたし、こんなにいっぱい例外投げてるゥゥッ！
ぶびびびびびびびぃぃぃぃぃぃぃっっっっ！！！！ボトボトボトォォッッ！！！
ぁあ…例外投げるっ、例外投げますうっ！！
ビッ、ブリュッ、ブリュブリュブリュゥゥゥーーーーーッッッ！！！
いやああああっっっ！！見ないで、お願いぃぃぃっっっ！！！
ブジュッ！ジャアアアアーーーーーーッッッ…ブシャッ！
ブババババババアアアアアアッッッッ！！！！
んはああーーーーっっっ！！！ウッ、ウンッ、例外ォォォッッ！
面白いと思ってやってるんだろうねきっと
>いやああああっっっ！！見ないで、お願いぃぃぃっっっ！！！
>例外見てぇっ ああっ、もうダメッ！！はうあああーーーーっっっ！！！
どっちやねん (´・ω・`)
>例外見てぇっ ああっ、もうダメッ！！はうあああーーーーっっっ！！！
どっちやねん (´・ω・`)
どうなれば例外を正しく使えてることになるの？
エサ投入っすか
最近見たよろしくないパターン
try
{
～
}
catch (Exception e)
{
logger.error("", e);
不具合とかがない限りはかならず業務例外的なものなので、相応の回復処理
}
↓続行(リトライや、再スローではない)
だめなところ：
・原因が分かってて適切に復旧してるのに、利用価値のないスタックトレースをログに吐いてる。
・もっと厳密な型指定ができるのにException型で捕捉している。
try
{
～
}
catch (Exception e)
{
logger.error("", e);
不具合とかがない限りはかならず業務例外的なものなので、相応の回復処理
}
↓続行(リトライや、再スローではない)
だめなところ：
・原因が分かってて適切に復旧してるのに、利用価値のないスタックトレースをログに吐いてる。
・もっと厳密な型指定ができるのにException型で捕捉している。
水を得た魚かよｗ
何が悪いのか、全然わっかりましぇーん
>>856
・業務例外ならログは必要。スタックトレースはloggerの責任
・業務例外的なものならば、Exceptionを捕捉しても問題は起きない。
将来の仕様変更は怖いが、それは厳密な型指定をしても変わらない
・業務例外ならログは必要。スタックトレースはloggerの責任
・業務例外的なものならば、Exceptionを捕捉しても問題は起きない。
将来の仕様変更は怖いが、それは厳密な型指定をしても変わらない
正常系に復旧するログなんぞデバッグかせめてinfoで吐けよ
例外=どうしようもない異常って思ってる奴多いよな
例外=どうしようもない異常って思ってる奴多いよな
誰も見ないのは嫌だけど、見て欲しくない奴には見られたくない。
メンヘラ女みたいな理屈だな。
メンヘラ女みたいな理屈だな。
>>860
お前、アホだなｗ
お前、アホだなｗ
例外とエラーは違うだろ。
>>862
把握してない例外をどうするかの話だろ？
対処すれば既知のエラーになるが、把握してない例外というのは、
それ以外の例外をどうするかって話をしてるんだよ。
すべての例外に対応するというのなら、大変になるだろうけどそれはそれでいいよ。
ただ思うのは、例外ごとにそれを処理するコードが一緒なら
一つにまとめたほうがいいんじゃね？ってこと。
例外ごとに違った処理をすることはあるし、だから
区別できるように型が分かれているわけだが、
殆どの場合どんな例外でも同じ処理コードになる。
結果的に、ほとんどの例外を取り扱う一つの共通コードと
違った処理をしたい時に、ほんの少し特別なコードを書くことになる。
（さらに言うならば、共通コードとしてなにもしないでいい、つまり省略してOKな場合も多い）
把握してない例外をどうするかの話だろ？
対処すれば既知のエラーになるが、把握してない例外というのは、
それ以外の例外をどうするかって話をしてるんだよ。
すべての例外に対応するというのなら、大変になるだろうけどそれはそれでいいよ。
ただ思うのは、例外ごとにそれを処理するコードが一緒なら
一つにまとめたほうがいいんじゃね？ってこと。
例外ごとに違った処理をすることはあるし、だから
区別できるように型が分かれているわけだが、
殆どの場合どんな例外でも同じ処理コードになる。
結果的に、ほとんどの例外を取り扱う一つの共通コードと
違った処理をしたい時に、ほんの少し特別なコードを書くことになる。
（さらに言うならば、共通コードとしてなにもしないでいい、つまり省略してOKな場合も多い）
>>848
> 少なくともファイル読み込みミスった程度で投げられてはたまったものではない
ファイル読み込みミスったらどうしようもないだろ。
だから、例外を返すか、戻り値でエラーを返すかするしかないはずだが。
> 少なくともファイル読み込みミスった程度で投げられてはたまったものではない
ファイル読み込みミスったらどうしようもないだろ。
だから、例外を返すか、戻り値でエラーを返すかするしかないはずだが。
「例外ごとに違った処理」っていう考え方が既に間違い。
その間違いという理由を言わないから、お前のレスは無視されるぞｗ
同じエラーでも起きた状況によって違う処理を行う必要があることの方が多い。
まぁサンプルプログラム程度の内容なら
例外の種類で分けてもいいのかもしれないが。
例外の種類で分けてもいいのかもしれないが。
さっきから理由がないな
まあ、戻り値でエラーを返せば、
なにか問題が解決するかというと
何も解決しないわけで、これは例外の問題ではない。
なにか問題が解決するかというと
何も解決しないわけで、これは例外の問題ではない。
>>868
痛いところ突いたら無視されるのはいつものことだから慣れたよ。
痛いところ突いたら無視されるのはいつものことだから慣れたよ。
理由を言ってないのに、痛いところをついたつもりでいるの？不思議ｗ
思うのは、例外を理解してない人って、
例外を出す側と
例外を受け取る側の
区別が付いてないんだろうね。
この二つの区別が付いてないから、
例外を出す側がやるべき仕事を
例外を受け取った人がやると考えてるかのような
発言が見られる。
たとえばファイルが読めなかったときにデフォルトの値を返す関数。
例外を出すのは、（デフォルトの値を返す関数が内部で使用している）ファイルを読み込む関数で、
デフォルトの値を返す関数は、（ファイルを読み込む関数の）例外を受け取る側
例外を出す側と
例外を受け取る側の
区別が付いてないんだろうね。
この二つの区別が付いてないから、
例外を出す側がやるべき仕事を
例外を受け取った人がやると考えてるかのような
発言が見られる。
たとえばファイルが読めなかったときにデフォルトの値を返す関数。
例外を出すのは、（デフォルトの値を返す関数が内部で使用している）ファイルを読み込む関数で、
デフォルトの値を返す関数は、（ファイルを読み込む関数の）例外を受け取る側
もう一つ、例外を出す側と
例外を受け取る側の区別が付いてない人へ。
なにか異常状態が起きたら例外を出す。
そのとき、異常状態を回復させるのは、例外を出す側が、例外を送出する前に行う仕事で、
例外を受け取る側の仕事は、異常状態が発生した後の処理の流れを決めること。
例外を受け取る側の区別が付いてない人へ。
なにか異常状態が起きたら例外を出す。
そのとき、異常状態を回復させるのは、例外を出す側が、例外を送出する前に行う仕事で、
例外を受け取る側の仕事は、異常状態が発生した後の処理の流れを決めること。
既に異常状態から回復してるんなら、通知してこなくていいよ。
せめてログに出すくらいで止めといてよ。
せめてログに出すくらいで止めといてよ。
だから例外を出す側は通知するのが仕事、
無視するかしないかを決めるのは、例外を受け取る側の仕事
ちゃんと区別をつけようぜ。
無視するかしないかを決めるのは、例外を受け取る側の仕事
ちゃんと区別をつけようぜ。
そもそも「異常状態から回復しました」ってのを通知されてどうするんだよ。
そのまま処理続行する以外の選択肢があるのか？
そのまま処理続行する以外の選択肢があるのか？
そこでなんで例外返すのうざいよ
処理きれちゃうじゃん
お前がその意味不明な例外なげるからtry catchで囲めないよ的な
つまり、例外を投げる危険度フェイズがプロジェクトで統一されてないと
そいつの主観にいちいちあわせなくちゃいけなくて面倒臭い
処理きれちゃうじゃん
お前がその意味不明な例外なげるからtry catchで囲めないよ的な
つまり、例外を投げる危険度フェイズがプロジェクトで統一されてないと
そいつの主観にいちいちあわせなくちゃいけなくて面倒臭い
例外むかつく
try{
FILE *f = fopen();
fread();
unko();
fread();
chinko();←例外発生
fread();
manko();
fclose(f);
}catch{
略
}
ファイル閉じらんねー！
try{
FILE *f = fopen();
fread();
unko();
fread();
chinko();←例外発生
fread();
manko();
fclose(f);
}catch{
略
}
ファイル閉じらんねー！
>>880
お前なにか勘違いしてるぞ。
異常状態と異常事態は違う。
異常状態を回復させたのち、
異常が発生しましたと事態を通知するんだよ。
そもそも、関数の中身はブラックボックスとして
扱うのだから、異常事態が発生したという通知はできるが、
どんな異常な状態になっているかは、例外を発生させる関数にしかわからない。
だからその回復方法も例外を発生させる関数にしかわからない。
そして異常状態を回復させ、関数から異常が発生したと伝えたら、
今度は例外を受け取る側の仕事で、
異常終了するか、無視して続行するか、
（引数を変えるなどして）リトライするかを選べる。
お前なにか勘違いしてるぞ。
異常状態と異常事態は違う。
異常状態を回復させたのち、
異常が発生しましたと事態を通知するんだよ。
そもそも、関数の中身はブラックボックスとして
扱うのだから、異常事態が発生したという通知はできるが、
どんな異常な状態になっているかは、例外を発生させる関数にしかわからない。
だからその回復方法も例外を発生させる関数にしかわからない。
そして異常状態を回復させ、関数から異常が発生したと伝えたら、
今度は例外を受け取る側の仕事で、
異常終了するか、無視して続行するか、
（引数を変えるなどして）リトライするかを選べる。
閉じれよ
try{
FILE *f = fopen();
fread();
unko();
fread();
chinko();←例外発生
fread();
manko();
}catch{
略
} finally {
if(!f) fclose(f)
}
try{
FILE *f = fopen();
fread();
unko();
fread();
chinko();←例外発生
fread();
manko();
}catch{
略
} finally {
if(!f) fclose(f)
}
>>884
スコープ的にそれっていけるのか？
スコープ的にそれっていけるのか？
>>885
訂正する方法ぐらい思いつくだろ。
訂正する方法ぐらい思いつくだろ。
これが戻り値だと・・・
FILE *f = fopen();
fread();
unko();
fread();
chinko(); ←エラー発生
fread();
manko(); ←チンコが異常事態なのにマンコしてしまう
fclose(f);
FILE *f = fopen();
fread();
unko();
fread();
chinko(); ←エラー発生
fread();
manko(); ←チンコが異常事態なのにマンコしてしまう
fclose(f);
戻り値・・・？
>>882 RAII くらい覚えれ。
>>887を例外を出さないでgotoも使わないで正しく修正すると
FILE *f = fopen();
if(!f) {
return FOPEN_ERROR;
}
if(fread()< 0) {
fclose(f);
return FREAD_ERROR;
}
if(unko()<0) {
fclose(f);
return UNKO_ERROR;
}
if(fread()< 0) {
fclose(f);
return FREAD_ERROR;
}
if(chinko()<0) { ←エラー発生
fclose(f);
return CHINKO_ERROR;
}
if(fread()< 0) {
fclose(f);
return FREAD_ERROR;
}
if(manko()<0) {
fclose(f);
return MANKO_ERROR;
}
fclose(f);
return SUCCESS;
FILE *f = fopen();
if(!f) {
return FOPEN_ERROR;
}
if(fread()< 0) {
fclose(f);
return FREAD_ERROR;
}
if(unko()<0) {
fclose(f);
return UNKO_ERROR;
}
if(fread()< 0) {
fclose(f);
return FREAD_ERROR;
}
if(chinko()<0) { ←エラー発生
fclose(f);
return CHINKO_ERROR;
}
if(fread()< 0) {
fclose(f);
return FREAD_ERROR;
}
if(manko()<0) {
fclose(f);
return MANKO_ERROR;
}
fclose(f);
return SUCCESS;
なんかもうスレタイと全く話が違うし、
すでに宗教論争と化してるな。
すでに宗教論争と化してるな。
いいんじゃね？
例外を正しく使えない人って、
例外を使えない人、戻り値エラーが劣っていることこを
認められない人なんだから。
使ってないものを毛嫌いする人は、
単にその技術を理解してないことを
認めたくないだけなんだって。
例外を正しく使えない人って、
例外を使えない人、戻り値エラーが劣っていることこを
認められない人なんだから。
使ってないものを毛嫌いする人は、
単にその技術を理解してないことを
認めたくないだけなんだって。
> 各種ERRORはfalseで成功時はtrueでいいと思うけど
だめ。
戻り側で区別できない。
だめ。
戻り側で区別できない。
>>893
> まったく問題無くかつ美しいソースだな
>
> これが一番見やすく修正しやすいソースだとなぜ気がつかない
俺はこのコードの何が悪いかなんて言ってないんだけど、
俺が言いたいことと逆のことを的確に言えるってことは、
君は、本当は自分で見にくくて修正しづらいって
気づいているだよ。
> まったく問題無くかつ美しいソースだな
>
> これが一番見やすく修正しやすいソースだとなぜ気がつかない
俺はこのコードの何が悪いかなんて言ってないんだけど、
俺が言いたいことと逆のことを的確に言えるってことは、
君は、本当は自分で見にくくて修正しづらいって
気づいているだよ。
>>896
は？なんで？
俺、こうやって単調にずらずら書けるソースが一番好きだよ
多分、君は馬鹿だからこういうの嫌いだと思ったんだ
よくみてごらん
これは必要な記述であってこれを圧縮したところで必要な記述が消えてしまってるだけで
なにもいいコードではない
これが経験が足りない君にはわからないんだよ
は？なんで？
俺、こうやって単調にずらずら書けるソースが一番好きだよ
多分、君は馬鹿だからこういうの嫌いだと思ったんだ
よくみてごらん
これは必要な記述であってこれを圧縮したところで必要な記述が消えてしまってるだけで
なにもいいコードではない
これが経験が足りない君にはわからないんだよ
>>898
単調だから良いって思っている時点でだめだな。
コピペされたコードが美しいって感じる。
似たようなコードが並んでいると美しい。
そんなタイプの人間だろ？
同じコードが重複しているということに
気づかないのか？
単調だから良いって思っている時点でだめだな。
コピペされたコードが美しいって感じる。
似たようなコードが並んでいると美しい。
そんなタイプの人間だろ？
同じコードが重複しているということに
気づかないのか？
>>898
> これは必要な記述であってこれを圧縮したところで必要な記述が消えてしまってるだけで
> なにもいいコードではない
言語機能を把握することで記述を簡素化できることを良しとしない
って理論だと、 for や while も if と goto で書き直すことにならない？
でもきっとそんなことはしないだろう。
何が違うの？
> これは必要な記述であってこれを圧縮したところで必要な記述が消えてしまってるだけで
> なにもいいコードではない
言語機能を把握することで記述を簡素化できることを良しとしない
って理論だと、 for や while も if と goto で書き直すことにならない？
でもきっとそんなことはしないだろう。
何が違うの？
「俺がよく理解しているかどうか」が違うに決まってる。
一つの型に複数の意味を持たせ、正常と異常が混在させるほうがいいって考えがまず古いよな
新しい仕組みが理解できない奴には、ついて行けないのかもしれないけれど
新しい仕組みが理解できない奴には、ついて行けないのかもしれないけれど
>>903
は？俺は成功と失敗でいいっていったけどね
は？俺は成功と失敗でいいっていったけどね
綺麗に書けるからいいソース(ｷﾘｯ
へんな拘り持ってるマにろくな奴はいねぇ法則だな
言語仕様とかコーディングルールとか無視して好き勝手やる糞の典型
へんな拘り持ってるマにろくな奴はいねぇ法則だな
言語仕様とかコーディングルールとか無視して好き勝手やる糞の典型
少なくとも似たようなレスはまとめていいと思う。
なんでもかんでもけずってコードを減らせばいいコードだと思ってる痛い奴がいてこまったもんだな
そうだな
ステップ数で見積もりたててるのに減らせとか馬鹿じゃねーの
ステップ数で見積もりたててるのに減らせとか馬鹿じゃねーの
①データベースに接続されていません→②再接続→③接続できた！
的な流れなら①の報告はいるようないらないような？
的な流れなら①の報告はいるようないらないような？
>>902
それは確かにそうだが、「失敗したら必要なクリーンアップを行って呼び出し元に
通知する」という部分は「似ている」のではなく「全く同じ」なわけで、しかも大量なわけで、
これをまとめない理由は無い。
それは確かにそうだが、「失敗したら必要なクリーンアップを行って呼び出し元に
通知する」という部分は「似ている」のではなく「全く同じ」なわけで、しかも大量なわけで、
これをまとめない理由は無い。
>>911
それで無駄にまとめて一つでも変更があったら面倒臭いコード書いちゃうんだな
今、たまたま同じ仕様なだけで
オープンからクローズまで対処を「そろえる」
とまでは書いた仕様書なんてねーだろ？
そこを歪曲して勝手にそろえちゃうってのはお前の妄想じゃね？
同じ処理した関数おくぐらいでやめるべきだろ
それで無駄にまとめて一つでも変更があったら面倒臭いコード書いちゃうんだな
今、たまたま同じ仕様なだけで
オープンからクローズまで対処を「そろえる」
とまでは書いた仕様書なんてねーだろ？
そこを歪曲して勝手にそろえちゃうってのはお前の妄想じゃね？
同じ処理した関数おくぐらいでやめるべきだろ
例外を投げるなって言ってる人はあれだよね
理解できなくて、処理も回復もできないからって、回りに不満例外を投げまくってる感じだよね
たしかに本来ならそれは内部で回復するべき例外だから、回りに投げ散らかされたら、迷惑ではある
まぁ例え処理がろくにできない不具合メソッドでも、周りがちゃんと捕捉してくれてるうちは、とりあえず何とかなるわけだ
>>912
それは例外を使うことの問題ではなく、設計が糞だって話だよね
再三言われてるけど、そういう話じゃないでしょ
それに、911がいってる「まとめる」ってのは、同じ回復処理が出来るものについての話でしょ
なんでリソースの取得から開放までの処理を共通化してる話みたいに捉えちゃってんの
共通の例外を投げる場合、受ける側は1箇所ですむから、
下位の処理が増えたりしても回復処理側の変更が必要なくなるわけで、
テスト工数が減らせるわけだし、同じようなコードが複数ちりばめられる心配もないっしょ
関係ないついでにいうと、コピペで似たような処理を量産した場合に
その全てに同じ修正が必要になる可能性だってあるっしょ
単体の工数考えたら、相当頭の悪いやり方だぞ
理解できなくて、処理も回復もできないからって、回りに不満例外を投げまくってる感じだよね
たしかに本来ならそれは内部で回復するべき例外だから、回りに投げ散らかされたら、迷惑ではある
まぁ例え処理がろくにできない不具合メソッドでも、周りがちゃんと捕捉してくれてるうちは、とりあえず何とかなるわけだ
>>912
それは例外を使うことの問題ではなく、設計が糞だって話だよね
再三言われてるけど、そういう話じゃないでしょ
それに、911がいってる「まとめる」ってのは、同じ回復処理が出来るものについての話でしょ
なんでリソースの取得から開放までの処理を共通化してる話みたいに捉えちゃってんの
共通の例外を投げる場合、受ける側は1箇所ですむから、
下位の処理が増えたりしても回復処理側の変更が必要なくなるわけで、
テスト工数が減らせるわけだし、同じようなコードが複数ちりばめられる心配もないっしょ
関係ないついでにいうと、コピペで似たような処理を量産した場合に
その全てに同じ修正が必要になる可能性だってあるっしょ
単体の工数考えたら、相当頭の悪いやり方だぞ
たまたま同じ処理だから共通処理にするってのは、はっきり言って下手な設計方針。
>>912
仕様書に↓こんなふうにいちいち全部書いてあるってこと？
1. まずファイルを開きます。開けなかったらエラーを返します。
2. 4 バイトを～として読み込みます。読み込めなかったらファイルを閉じてエラーを返します。
3. 1 バイトを～として読み込みます。読み込めなかったらファイルを閉じてエラーを返します。
4. 1 バイトを～として読み込みます。読み込めなかったらファイルを閉じてエラーを返します。
5. 1 バイトを～として読み込みます。読み込めなかったらファイルを閉じてエラーを返します。
略
X. ファイルを閉じます。失敗したらエラーを返します。
ほんとうにこう書いてある仕様書に対する実装をするなら >>890 が正解なんだろうけど、
全部にそんなのが書いてあることもないだろうし、書いてあったらやめてくれと頼んでも
いいところだろう。
仕様書に↓こんなふうにいちいち全部書いてあるってこと？
1. まずファイルを開きます。開けなかったらエラーを返します。
2. 4 バイトを～として読み込みます。読み込めなかったらファイルを閉じてエラーを返します。
3. 1 バイトを～として読み込みます。読み込めなかったらファイルを閉じてエラーを返します。
4. 1 バイトを～として読み込みます。読み込めなかったらファイルを閉じてエラーを返します。
5. 1 バイトを～として読み込みます。読み込めなかったらファイルを閉じてエラーを返します。
略
X. ファイルを閉じます。失敗したらエラーを返します。
ほんとうにこう書いてある仕様書に対する実装をするなら >>890 が正解なんだろうけど、
全部にそんなのが書いてあることもないだろうし、書いてあったらやめてくれと頼んでも
いいところだろう。
関数で閉じてりゃ、そんなもんどっちでも良いわ。
918 ：仕様書無しさん：2011/02/18(金) 07:46:57
>>880
同意
同意
>>920 それは回復できてないと言うんじゃないか？
922 ：仕様書無しさん：2011/02/18(金) 08:14:08
なぜ？
だって正常に終わったと言えないんだろ？
違うんなら何を「回復」したっていうの？その「回復」に何の意味があるの？
違うんなら何を「回復」したっていうの？その「回復」に何の意味があるの？
何のReadに失敗したか分からん時点でエラーコードを分けてる意味が無い
戻り値の人が言うようにtrue/falseだけを返すコード
FILE *f = fopen();
if(!f) {
goto ERROR;
}
if(fread()< 0) {
goto ERROR;
}
if(unko()<0) {
goto ERROR;
}
if(fread()< 0) {
goto ERROR;
}
if(chinko()<0) { ←エラー発生
goto ERROR;
}
if(fread()< 0) {
goto ERROR;
}
if(manko()<0) {
goto ERROR;
}
fclose(f);
return true;
ERROR:
if(!f){ fclose(f); }
return false;
FILE *f = fopen();
if(!f) {
goto ERROR;
}
if(fread()< 0) {
goto ERROR;
}
if(unko()<0) {
goto ERROR;
}
if(fread()< 0) {
goto ERROR;
}
if(chinko()<0) { ←エラー発生
goto ERROR;
}
if(fread()< 0) {
goto ERROR;
}
if(manko()<0) {
goto ERROR;
}
fclose(f);
return true;
ERROR:
if(!f){ fclose(f); }
return false;
>>912
エラー処理で一部分だけ変更があった時は、catch節を１つ書き足すだけだよ。
エラー処理で一部分だけ変更があった時は、catch節を１つ書き足すだけだよ。
>>927
gotoで飛ばすのは勘弁
gotoで飛ばすのは勘弁
>>928
出してた例外を出さなくなった
出してた例外を出さなくなった
>>929
例えばdo-while(0)でbreakならいいの？
例えばdo-while(0)でbreakならいいの？
>>913
その手の煽りは、もう飽きた。
その手の煽りは、もう飽きた。
>>931
それがいいと思うなら使えよ
それがいいと思うなら使えよ
>>927
それ何かちがくね？
それ何かちがくね？
>>933
いや、俺は別にgotoでいいよ
いや、俺は別にgotoでいいよ
&& で繋いだ if 文で事足りるだろうが。
途中で偽が帰って来たら、後に連なってる関数は呼び出されない。
見た目にもスッキリしてるから、言う事なし。
途中で偽が帰って来たら、後に連なってる関数は呼び出されない。
見た目にもスッキリしてるから、言う事なし。
937 ：仕様書無しさん：2011/02/18(金) 20:18:07
馬鹿
938 ：仕様書無しさん：2011/02/18(金) 20:19:01
もうね、例外しか使わない星に移住しなよ。
940 ：仕様書無しさん：2011/02/18(金) 20:29:07
goto はエラー処理限定ならばどんどん使って結構。
ただし上に戻るgotoは駄目。 複雑な3重ループ構造内のcontinueとかもだめだな
エラー処理以外のgotoはもちろんだめ。と統一すればgotoのほうがシンプルに
エラー処理を表現できる。
ただし上に戻るgotoは駄目。 複雑な3重ループ構造内のcontinueとかもだめだな
エラー処理以外のgotoはもちろんだめ。と統一すればgotoのほうがシンプルに
エラー処理を表現できる。
ファイルのオープン用の関数が例外投げないのはなんでだ？
お前の理屈だと、その関数作った奴が、例外をうまく使えないからか？
お前の理屈だと、その関数作った奴が、例外をうまく使えないからか？
＞ファイルのオープン用の関数が例外投げないのはなんでだ？
投げるけど？
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/io/FileReader.html
http://msdn.microsoft.com/ja-jp/library/f2ke0fzy.aspx
投げるけど？
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/io/FileReader.html
http://msdn.microsoft.com/ja-jp/library/f2ke0fzy.aspx
>ArgumentException path が空の文字列 ("") です。
>ArgumentNullException path が Nothing です。
>FileNotFoundException ファイルが見つかりません。
>DirectoryNotFoundException 割り当てられていないドライブであるなど、指定されたパスが無効です。
そのくらい、事前に自分でチェックして、クリアしてからアクセスしに行こうとするだろ普通。
>FileNotFoundException - ファイルが存在しないか、普通のファイルではなく
>ディレクトリであるか、または何らかの理由で開くことができない場合
これで、どうやって原因特定できるの？ 何らかの理由って？
>ArgumentNullException path が Nothing です。
>FileNotFoundException ファイルが見つかりません。
>DirectoryNotFoundException 割り当てられていないドライブであるなど、指定されたパスが無効です。
そのくらい、事前に自分でチェックして、クリアしてからアクセスしに行こうとするだろ普通。
>FileNotFoundException - ファイルが存在しないか、普通のファイルではなく
>ディレクトリであるか、または何らかの理由で開くことができない場合
これで、どうやって原因特定できるの？ 何らかの理由って？
例外を使えない人って、設計って概念がない気がする。
行き当たりばったりとまでは言わないけど、
こういう時にどうするってパターンが出来てない。
ぶっちゃけさ、デザインパターンって使ってる？
デザインパターンも例外を使うことを前提にしてコードが書いてあるよね。
行き当たりばったりとまでは言わないけど、
こういう時にどうするってパターンが出来てない。
ぶっちゃけさ、デザインパターンって使ってる？
デザインパターンも例外を使うことを前提にしてコードが書いてあるよね。
要するに、やるべき事もやらないくせに、いっちょ前の事をやろうとして、
処理系に例外という形で厳しく突っ込まれてるんじゃん。
処理系に例外という形で厳しく突っ込まれてるんじゃん。
例外の素晴らしい点の一つは、
hoge(unko(chinpo());
このような書き方をしても、どの関数でエラーが
起きたかちゃんとスタックトレースに表示されることだよな。
hoge(unko(chinpo());
このような書き方をしても、どの関数でエラーが
起きたかちゃんとスタックトレースに表示されることだよな。
例外というオムツのお世話になってます（ｷﾘｯ
>>949
省略しないで書けよ。
省略しないで書けよ。
省略しなかったら汚いのがバレるだろｗ
戻り値エラーの何がいけないかというと
その理由の一つは、エラーを意味する値が
なにか決まってないことだな。
だからエラー処理を一つにまとめることができない。
その理由の一つは、エラーを意味する値が
なにか決まってないことだな。
だからエラー処理を一つにまとめることができない。
http://msdn.microsoft.com/ja-jp/library/f2ke0fzy.aspx
↑
のサンプルコード、
> Try
（中略）
> Catch e As Exception
> Console.WriteLine("The process failed: {0}", e.ToString())
> End Try
「ファイルまたはコマンドが違います」以上の価値がある事を言ってない。
↑
のサンプルコード、
> Try
（中略）
> Catch e As Exception
> Console.WriteLine("The process failed: {0}", e.ToString())
> End Try
「ファイルまたはコマンドが違います」以上の価値がある事を言ってない。
>>953
それサンプルコードだから
それサンプルコードだから
>>948
だーかーらー、オマエは迂闊すぎるんだってば。 オマエが例外に
期待してる事は、例えばの話、
「一旦停止して左右確認せずに見通しの悪い交差点に進入して、万一
側面衝突しても、安全装備で死なないような車であるべき。」
とか言ってるのと同じ。
だーかーらー、オマエは迂闊すぎるんだってば。 オマエが例外に
期待してる事は、例えばの話、
「一旦停止して左右確認せずに見通しの悪い交差点に進入して、万一
側面衝突しても、安全装備で死なないような車であるべき。」
とか言ってるのと同じ。
>>953
これだけのことを言ってくれるけど？
パスが間違っている場合
The process failed: System.IO.DirectoryNotFoundException: パス 'c:\temp2\MyTest.txt' の一部が見つかりませんでした。
場所 System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
場所 System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURI
String msgPath, Boolean bFromProxy, Boolean useLongPath)
場所 System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
場所 System.IO.StreamWriter.CreateFile(String path, Boolean append)
場所 System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
場所 System.IO.StreamWriter..ctor(String path)
場所 ConsoleApplication3.Program.Main(String[] args) 場所 c:\users\username\documents\visual studio 2010\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs:行 21
ファイルを読み取り専用にした場合
The process failed: System.UnauthorizedAccessException: パス 'c:\temp\MyTest.txt' へのアクセスが拒否されました。
場所 System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
場所 System.IO.File.Delete(String path)
場所 ConsoleApplication3.Program.Main(String[] args) 場所 c:\users\username\documents\visual studio 2010\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs:行 18
これだけのことを言ってくれるけど？
パスが間違っている場合
The process failed: System.IO.DirectoryNotFoundException: パス 'c:\temp2\MyTest.txt' の一部が見つかりませんでした。
場所 System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
場所 System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURI
String msgPath, Boolean bFromProxy, Boolean useLongPath)
場所 System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
場所 System.IO.StreamWriter.CreateFile(String path, Boolean append)
場所 System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
場所 System.IO.StreamWriter..ctor(String path)
場所 ConsoleApplication3.Program.Main(String[] args) 場所 c:\users\username\documents\visual studio 2010\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs:行 21
ファイルを読み取り専用にした場合
The process failed: System.UnauthorizedAccessException: パス 'c:\temp\MyTest.txt' へのアクセスが拒否されました。
場所 System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
場所 System.IO.File.Delete(String path)
場所 ConsoleApplication3.Program.Main(String[] args) 場所 c:\users\username\documents\visual studio 2010\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs:行 18
ファイル名を「:」という不正な名前にしたとき
The process failed: System.ArgumentException: パスの形式が無効です。
場所 System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
場所 System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_AT
String msgPath, Boolean bFromProxy, Boolean useLongPath)
場所 System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
場所 System.IO.StreamWriter.CreateFile(String path, Boolean append)
場所 System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
場所 System.IO.StreamWriter..ctor(String path)
場所 ConsoleApplication3.Program.Main(String[] args) 場所 c:\users\username\documents\visual studio 2010\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs:行 21
The process failed: System.ArgumentException: パスの形式が無効です。
場所 System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
場所 System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_AT
String msgPath, Boolean bFromProxy, Boolean useLongPath)
場所 System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
場所 System.IO.StreamWriter.CreateFile(String path, Boolean append)
場所 System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
場所 System.IO.StreamWriter..ctor(String path)
場所 ConsoleApplication3.Program.Main(String[] args) 場所 c:\users\username\documents\visual studio 2010\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs:行 21
>>955
勝手にそんな事言っていることにするなよｗ
勝手にそんな事言っていることにするなよｗ
だいたい、>>943みたいな例外投げてもらって原因が分かったとして、
その後どうするんだ？ リトライか？
オマエは、ロクに設計もしてないクソコードを殴り書きして、例外起こして
原因を処理系に教えてもらってデバッグしてるクサレプログラマーだろが。
その後どうするんだ？ リトライか？
オマエは、ロクに設計もしてないクソコードを殴り書きして、例外起こして
原因を処理系に教えてもらってデバッグしてるクサレプログラマーだろが。
よく考えて実装してたら、運用段階でそんな例外投げられないっちゅの。
オマエは、
「自分が書いたコードの影響範囲が自分で良く分からんから、例外投げて
もらって原因特定しないとロクにデバッグも出来ません」
って意味の事をずっと言ってた訳だ。
オマエは、
「自分が書いたコードの影響範囲が自分で良く分からんから、例外投げて
もらって原因特定しないとロクにデバッグも出来ません」
って意味の事をずっと言ってた訳だ。
> よく考えて実装してたら、運用段階でそんな例外投げられないっちゅの。
開発段階は？
開発段階は？
>開発段階は？
図星だったかｗ
図星だったかｗ
机上デバッグをしている時代に人にとっては
コンピュータに開発の手伝いをしてもらうのは
恥だと思ってるんだよ。
コンピュータに開発の手伝いをしてもらうのは
恥だと思ってるんだよ。
例外を使えない人って、設計って概念がない気がする。
行き当たりばったりとまでは言わないけど、
こういう時にどうするってパターンが出来てない。
ぶっちゃけさ、デザインパターンって使ってる？
デザインパターンも例外を使うことを前提にしてコードが書いてあるよね。
行き当たりばったりとまでは言わないけど、
こういう時にどうするってパターンが出来てない。
ぶっちゃけさ、デザインパターンって使ってる？
デザインパターンも例外を使うことを前提にしてコードが書いてあるよね。
>>962
> 「自分が書いたコードの影響範囲が自分で良く分からんから、例外投げて
> もらって原因特定しないとロクにデバッグも出来ません」
例外ってすげーなｗ
自分が書いたコードの影響範囲までもわかるのかｗ
っていうかお前アホだろ？
なんで例外を全知全能の神みたいに思ってるんだ？
例外を分かってないやつの、典型的な想像だな。
> 「自分が書いたコードの影響範囲が自分で良く分からんから、例外投げて
> もらって原因特定しないとロクにデバッグも出来ません」
例外ってすげーなｗ
自分が書いたコードの影響範囲までもわかるのかｗ
っていうかお前アホだろ？
なんで例外を全知全能の神みたいに思ってるんだ？
例外を分かってないやつの、典型的な想像だな。
>例外を使えない人って、設計って概念がない気がする。
あのさあ、ファイルアクセスさせる処理呼び出す時に、空文字列ぶち
込んで、例外投げてもらって初めてその事に気付くようなコード書く
やり方が、正しい設計手法だとか本気で思ってんの？
起きてから対処するよりも、事前にある程度予防しておいた方が、よっ
ぽど安上がりだと思うんだが。 で、そういう風に開発する方が、よっぽ
どまっとうに設計してると思うんだが。
あのさあ、ファイルアクセスさせる処理呼び出す時に、空文字列ぶち
込んで、例外投げてもらって初めてその事に気付くようなコード書く
やり方が、正しい設計手法だとか本気で思ってんの？
起きてから対処するよりも、事前にある程度予防しておいた方が、よっ
ぽど安上がりだと思うんだが。 で、そういう風に開発する方が、よっぽ
どまっとうに設計してると思うんだが。
オマエは、ロクに設計もしてないクソコードを殴り書きして、例外起こして
原因を処理系に教えてもらってデバッグしてるクサレプログラマーだろが。
大事な事だから、もう一度言ってみました。 だってオマエ、都合の
悪い事は無視するから。
原因を処理系に教えてもらってデバッグしてるクサレプログラマーだろが。
大事な事だから、もう一度言ってみました。 だってオマエ、都合の
悪い事は無視するから。
972 ：仕様書無しさん：2011/02/18(金) 22:39:33
973 ：仕様書無しさん：2011/02/18(金) 22:40:30
設計なんて、ああたこいつらのレベルでは雲の上の話だぞ
974 ：仕様書無しさん：2011/02/18(金) 22:43:21
オブジェクト指向 危険な操作をする馬鹿を「安全」というラップでくるんだしくみ
デザインパターン よくある当たり前の組合せパターンすらわからない馬鹿にサンプルを提示した
デザインパターン よくある当たり前の組合せパターンすらわからない馬鹿にサンプルを提示した
975 ：仕様書無しさん：2011/02/18(金) 22:45:00
例外 エラー処理ができない馬鹿のために、あなたが書いたプログラムのこれとこれのメソッドで
ぬるちんぽエラーがおきましたよと教えてあげるしくみ
ぬるちんぽエラーがおきましたよと教えてあげるしくみ
例外がすごいのは
問題が発生しうる箇所全てに
予防コードが入っているということだ。
問題が発生しうる箇所全てに
予防コードが入っているということだ。
それって、普通でしょ
979 ：仕様書無しさん：2011/02/18(金) 23:49:44
>例外が素晴らしい物だと認められているからだよ。
そう思っているのはお前だけ >>975が真実
そう思っているのはお前だけ >>975が真実
980 ：仕様書無しさん：2011/02/18(金) 23:51:24
スタックに積み込んだメソッドの塊をちまちまトレースする仕組みについて
なんでこんなに大げさに語れるのか、それがまず不思議
なんでこんなに大げさに語れるのか、それがまず不思議
linuxとかだと、cでbacktraceって関数が使えるけど
誰が無関係だと決めたんだ？
同じ変数に入れる場合しか考えたことないのか？
そもそも検査例外と非検査例外区別して話してる？
バカには書けない例外の話でしょ
989 ：仕様書無しさん：2011/02/19(土) 00:50:49
馬鹿がさらにコードをくどくどしくぐでぐてにする仕組み
それが例外
それが例外
990 ：仕様書無しさん：2011/02/19(土) 00:53:02
ただでさえ増やしたくないネストブロックを
強引に try{}と増やしてくれるくどい仕組み。
それと、try{}に囲まなくてはならないメソッドとそうでないメソッドがあり
統一感もない。ぶっちゃけ、とってつけた仕様。そしてそれはやはり
エラー処理がまともにできない馬鹿をフォローする仕組みなのだよ。
だからぐでぐでつまらん例外についていつまでも語るな。
強引に try{}と増やしてくれるくどい仕組み。
それと、try{}に囲まなくてはならないメソッドとそうでないメソッドがあり
統一感もない。ぶっちゃけ、とってつけた仕様。そしてそれはやはり
エラー処理がまともにできない馬鹿をフォローする仕組みなのだよ。
だからぐでぐでつまらん例外についていつまでも語るな。
991 ：仕様書無しさん：2011/02/19(土) 00:55:02
あと、戻り値の複数エラーパターンについてぐでぐで言うおばかさん。
お前向いてないと思うよ。君の頭の構造ではもはや独学では限界なのでは?
お前向いてないと思うよ。君の頭の構造ではもはや独学では限界なのでは?
戻り値でも例外でも作り方が違うだけでどっちでもいいんだよ。
戻り値でやるとどうなのかは、例外の使い方には関係ない。
ただし混ぜるなキケン。
戻り値でやるとどうなのかは、例外の使い方には関係ない。
ただし混ぜるなキケン。
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はいらない)
メソッド(関数名): 自由につけろ
メソッド(関数)の型: 自由に考えろ
メソッドに渡す引数: 自由に考えろ
おこりうるエラーと捕獲するべき例外:自由に考えろ
さあ作ってみろ。馬鹿どもよ。
この場合は例外使ったほうがいいから、何でも例外使えばいいんだ
って勘違いする馬鹿が出るからやめれ。
って勘違いする馬鹿が出るからやめれ。
995 ：仕様書無しさん：2011/02/19(土) 01:17:03
関数の戻り値が正常な戻り値と
エラーコードの二種類の値を返すような場合、
例外を使ったほうがいいのは自明のこと。
エラーコードの二種類の値を返すような場合、
例外を使ったほうがいいのは自明のこと。
ケースバイケースでしょ
関数から戻り値を使うときに、
戻り値を使う前にその値がエラーかどうか
確認するようなコードがあれば
それは例外を使ったほうがいい印だよ。
戻り値を使う前にその値がエラーかどうか
確認するようなコードがあれば
それは例外を使ったほうがいい印だよ。
関数から戻り値はクリーンな値でなければならない。
もらった値はすぐに次の処理で使用できるべき。
つまり値として不正な物が含まれていてはいけない。
もらった値はすぐに次の処理で使用できるべき。
つまり値として不正な物が含まれていてはいけない。
戻り値にしかエラーが返せないと思うと例外って発想かいな？
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。