ぱっと見て「ヘタだなぁ」と思うコード　その５

1 名前：デフォルトの名無しさん [2006/08/12(土) 01:56:11 ] 禁止ネタ（超既出） ・長い関数 ・深いネスト ・グローバル変数 ・goto ・memset ・malloc - free ・局所ブロック ・サンプルコードのtypo ・記述スタイル ・関数・変数名 過去スレ その４： pc8.2ch.net/test/read.cgi/tech/1153312202/ その３： pc8.2ch.net/test/read.cgi/tech/1149986051/ その２： pc8.2ch.net/test/read.cgi/tech/1142741989/ 初代　： pc8.2ch.net/test/read.cgi/tech/1141867015/ 152 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 21:17:06 ] >>148 ・識別子が全部小文字で非常に見づらい。 単語の区切りが明確になるようにアンダーバーを入れれ。 ローカル変数も然り。 ・getdateinputinfってのが何なのかさっぱりわからんけど適切な命名ではないと思う。 ・getstreamopenでなくてis_stream_open。 名前だけ見ると別の意味になる。 ・コメントがなさすぎ。命名の微妙さとあいまって何をやってるコードなのかさっぱりわからん。 153 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 21:28:33 ] >>148 Error #503 Service Unavailable BoostWeb BW4.2.16.1 Feb 24 2003 at bw03 154 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 22:50:17 BE:404376899-2BP(201)] >>148 >if(b){ >   value += a; >}else{ >   value += a; >} これはバグ? 155 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 12:28:27 ] >>152 クラス名・変数名に迷ったら書き込むスレ。Part8 pc8.2ch.net/test/read.cgi/tech/1154448184/ ちょっと、行っています >>153 即行消されたのか・・・ >>154 消し忘れです 一応やってみました ttp://up2.viploader.net/mini/src/viploader63439.zip バグありでファイルを開いてインプットした後 閉じてもう一回読んだときファイルストリームができない・・・なぜ？ 156 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 01:10:43 ] ＞ファイルをとじらせるバグってる 日本語でOK。 157 名前：デフォルトの名無しさん [2006/08/28(月) 01:53:12 ] 開発で見かけた、Ｔ芝のコード。 関数の途中で数箇所return的な処理をする代わりにgoto使ってる。 void xxx() { : if( ... ) { goto END; } switdh( ... ) { case xxx: goto END; : } END: return; } ・・・こういう目的限定なら使ってもいいのか？俺は使わないが。 158 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 02:09:36 ] その例なら 普通に return した方が良い。 ただ、エラー処理が混じる場合は goto を使った方がエレガントに書けるので 積極的に使えば良いという人も少なからずいる。 (goto排除原理主義者はこれを認めない。) 159 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 03:26:26 ] 別に下手でも何でもないような。 まあ、行数多い中でやってるなら、分けろよとは思うかもしれないけど。 goto排他原理主義者って、なんであんなに頑ななんだろうね。 どう見ても使った方がいいだろって状況でも grepかけて突きつけてきたりするもんなー。 多重ループん中から抜ける時とか、同じ条件のifだだ並べにしてる方が 三億倍はキモいと思うんだが、何がそこまで彼らの憎しみを駆り立てるのか。 160 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 04:27:43 ] なんでも極端にやるのはダメだよねぇ… 以前“短い関数”原理主義者を見かけたよ。 ３行関数を大量生産したらかえって読みにくい。 161 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 05:52:50 ] C言語ならありかもしれないな。 C++では例外やアルゴリズムやオーバーロードがあるから gotoは完全にいらない子だけどね。 162 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 06:42:02 ] アルゴリズムもオーバーロードも関係ないと思われ。 例外は確かにあるが、多重ループから抜けるのなんかに使ってたら、それこそヘタなコードだろ。 場合によっちゃJavaでだってバカにされるわ。 C++の例外は、そもそもデストラクション絡みの負荷がデカすぎて 使用を呑めない場合すらあるしなー。 Cで許されるのと同程度の使い方なら、C++で使ってたって何の問題もないと思うんだが。 163 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 07:09:16 ] アルゴリズム類の適用で多重ループ自体の出番を減らせられるのは分かるが、 なんでもかんでもそれで書いてたら、それはそれで馬鹿なコードだな case文のラベル名指しで飛んでるようなコードは流石に有害指定してもいいとは思うが、 ぱっと見すぐわかる範囲で簡潔に使われてる程度で目くじら立てるのは… 164 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 13:10:51 ] よくあるのは、 : : return TRUE; /* ↑ここまで正常系処理 */ error: if (hoge) { hogeのリソースを解放; } if (fuga) { fugaのリソースを解放; } return ERROR; みたいなやつ。hoge/fuga/...は一連の処理の最初にNULLで初期化しておく。 途中で処理が失敗したとき、どのリソースが割り当てずみかを気にせず、 末尾に飛べばいい。 165 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 13:11:41 ] TRUE/ERRORってのは変な組み合わせだな。てきとーに読み替えplz 166 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 14:16:05 ] >C++では例外やアルゴリズムやオーバーロードがあるから なぜここにアルゴリズムが混じりますか？？ 167 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 14:35:00 ] >>160 > 以前“短い関数”原理主義者を見かけたよ。 Kent Beckのことですね。 168 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 14:47:44 ] >>164 正常系のリソース解放を一緒にすると下のようになるんだろうが、なんか微妙 なようなそうでないような。 result = SUCCESS; goto end; /* ↑ここまで正常系処理 */ error: result = FAILURE; end: if (...) if (...) return result; 169 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 20:30:04 ] >>162 なんでそんな例外を忌み嫌うのかよくわからん。 頭固いんじゃないの？ 170 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 23:10:24 ] >>162 > C++の例外は、そもそもデストラクション絡みの負荷がデカすぎて 必要なことをしているだけじゃないの？ 例外を使わなくたって、デストラクタを呼ぶ必要がなくなるわけじゃないでしょ？ 正常系の場合に(結果的に)無駄となることをする場合もあるけど、 例外を使うことによるメリットを考えれば普通は我慢できるはずだけど。 171 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 23:10:48 ] >>169 え？多重ループから抜け出すのに例外使うの？ 下手だなー。 172 名前：デフォルトの名無しさん mailto:sage [2006/08/28(月) 23:54:37 ] >>170 C++の例外処理は相当重たい処理だよ。 だからこそ例外を使わないというコンパイルオプションがあるくらいなのに。 173 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 00:26:04 ] >>168 頻出なイディオムなのに簡潔に書けないもんだから C++やその他の言語で try-catch が生まれたって流れなんでしょうね。 たまに C++ で書く時は finally 使えなくてムズムズする。 きちんとデストラクタ書けって話なんだけど。 174 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 01:03:40 ] >>167 Kent Beckに限らず、Smalltalkerはn行を超えるメソッド(関数)が ポコポコ出来るなんて信じられない、という発言を真顔でするね。 175 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 03:48:20 ] 多重ループじゃなくてイテレーションなら一発で抜けられるのにな 176 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 04:57:44 ] goto信者が暴れていたようだな。 そんなに早さを求めたいのならC++なんて使うな。 177 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 05:05:42 ] C++ではデストラクタ以外にリソース解放コードを書いてはいけない よってgotoはいらない 逆にスコープアウト時の処理が書けないレガシーな言語には必要。 Javaはgotoがないのでご覧のとおり悲惨なことになっている 178 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 08:51:11 ] ループを脱けるために例外を使うなんて、意味論的にも変だっつーの。 ところで、 LABEL: 　for(〜) { 　　for(〜) { 　　　if (〜) break LABEL; 　　} 　} で、外側のforまで一気に break してくれる構文のある言語があったような木がするんだけど、なんだっけ？ 179 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 10:01:15 ] ラベル付きbreakはJavaにはあるな。C♯は goto ラベルか。 Perlだとbreakじゃなくてlastだが、これもラベルがつけられる。 Rubyだと catch(:identifier) do throw :identifier end と書く。 # これは例外処理ではない。 180 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 10:02:43 ] D言語の言語仕様にはあったが実際どう動くかわからない 181 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 17:12:25 ] >>177 関数内のある処理のために確保した一時メモリ領域とかもデストラクタで解放するの？ C♯のfinally構文に慣れたせいかいまいち理解できない。 具体的にどう書くの？ 182 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:00:12 ] >>181 つ std::auto_ptr auto_ptrは腐ってるという意見もあるようだが。 183 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:10:39 ] phpは break n; でn段のネストから抜ける 184 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:20:49 ] 「n段」ってのがPHPらしい仕様だよな 185 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:44:12 ] >>182 ほへー。 それを徹底するくらいなら例外かgotoで終了処理したほうがよほどスマートだと思うんだけどな･･･ 186 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 19:48:14 ] >>182 auto_ptrはauto変数としてのみ使うもんだと思ってる。 移動コピーはcreate関数なんかに効率を落とさず対応するためのもので、 基本的にはコピーしない、と。 >>185 struct file { FILE *f; file(const char *path) { f = fopen(path, "r+"); } ~file() { fclose(f); } }; int main() { file f("foo.txt"); // 何かする } // close 187 名前：デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:08:06 ] 標準では未だにauto_arrayって入ってないんだっけ。 いや、自分で書いても一瞬だけどさ…。 188 名前：デフォルトの名無しさん mailto:sage [2006/08/30(水) 11:14:53 ] >>181 つ[More Effective C++] 189 名前：デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:01:50 ] >>181 C#使いなら、System.IDispose.Disposeに書くようなことをC++ではデストラクタに書くと言えば通じるだろうか。 ただしusingに相当するものはなく、自動変数ならスコープを抜けるときに呼ばれるという感じ。 190 名前：デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:03:20 ] すまん、IDisposableだったな。 >>186 auto_ptrを自動変数として使うだけなら、scoped_ptrでいいだろと思う俺。 今はまだBoostだから使用に抵抗を感じるのかもしれないけどね。 191 名前：デフォルトの名無しさん mailto:sage [2006/08/30(水) 22:13:15 ] boost馬鹿は死んでいいよ 192 名前：デフォルトの名無しさん mailto:sage [2006/08/30(水) 23:53:53 ] おまいが死んだら一番じゃん 193 名前：デフォルトの名無しさん [2006/08/31(木) 00:30:09 ] try{ … } catch(Exception e){ 　if(e instanceof HogeException){...} } もうね、アホカと。馬鹿かと。 194 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:36:44 ] ・飛んでくる例外の共通の親はException。 ・各例外を捕まえたときの処理は同じだが結構分量アリ。 ・捕まえずに上にそのまま通す例外もある みたいな条件が重なったときは結構困るな。 195 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:42:10 ] どういう場合にそういう状況に陥る？ 設計しなおすと結構シンプルになったりしそうなんだが。 196 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:45:16 ] ・飛んでくる例外の共通の親はException。 →当たり前。 ・各例外を捕まえたときの処理は同じだが結構分量アリ。 →メソッド化しろボケ。 ・捕まえずに上にそのまま通す例外もある →catchしてthrowするか、何もするな。 どこがどう困るんじゃと。 197 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:48:57 ] >>196 こいつ下手そう 198 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:05:51 ] そうでもないよ 199 名前：デフォルトの名無しさん [2006/08/31(木) 01:12:26 ] >>197 こう書いたらｴｴﾔﾝっていってるだけなんだけど、だめ？ void exampleFunction()throws BarException{ 　try{ 　 //FooException,BarException,BazExceptionが発生する可能性あり 　} 　catch(FooException e1){ 　 handleException(); 　} 　catch(BarException e2){ 　 throw e2; 　} 　catch(BazException e3){ 　　handleException(); 　} } 200 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:24:53 ] >>196 Exceptionまでさかのぼらないと共通の親クラスが見つからない、 だから、まとめて捕まえるならExceptionで捕まえるか、 別々に書くかしないといけない、ということだね。 201 名前：181 mailto:sage [2006/08/31(木) 05:10:40 ] >>189 いや、C++も昔やってたからその辺のことはわかってるよ。 ただ一時メモリ領域もデストラクタで解放するっていうことに違和感を覚えただけ。 202 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 10:34:47 ] BarException をcatchする意味がないじゃん。 handleException() は、handleException(e1) とかで多胎にするよーな？ 203 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 13:59:45 ] >>201 >一時メモリ領域 一瞬、スタック領域に取られたメモリの事かとおもた じゃなかったら一時的かどうかはコンパイラには解らないから 204 名前：181 mailto:sage [2006/08/31(木) 15:12:31 ] スタック領域だったらそもそも解放とか気にする必要がないのではｗ まあとりあえず自分の話題については>>182で一応の解決を見たのでこれ以上の問答は無用です。 205 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 21:21:42 ] 例外も仕様の内だと思うんだけど。 なんでtry-catchなんて使うんだろうね。 ifとtryのどっちを使うのか明確にわけてあるプロジェクトにあたったことないな。 206 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 22:14:56 ] >>205 こいつ下手そう 207 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 22:39:56 ] >>206 おお！trycatchの適切な利用方法を説明してみてくれ。 なんかパっとしねぇの多いんだ。 208 名前：デフォルトの名無しさん mailto:sage [2006/08/31(木) 23:30:19 ] >>202 rethrow する前にログったり BarException 固有の処理するけど 紙面の都合で省かれてるんだと思うことにしよう。 ＞ 多胎 派生例外クラスにありとあらゆるケースの例外処理が書かれて かえって可読性が下がる気がしなくもない。 209 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:23:55 ] 当然のことだが、例外クラスはそれを使うクラスのことは知らない。 まさか、1クラスにつき1例外作るとか言うんじゃないだろうな。 210 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:34:41 ] そう。だから例外処理で多態は困難に感じる。 211 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:40:22 ] ここで「こいつ下手そう」発言君↓ 212 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:42:04 ] >>211 こいつ下手そう 213 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:45:06 ] >>207 try { resA->open(); // res: resource resB->open(); resA->hoge(); resB->fuga(); resB->close(); resA->close(); } catch () { } 214 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:48:58 ] んなーこたーない 215 名前：213 mailto:sage [2006/09/01(金) 00:52:06 ] >>214 ん、俺？ 俺いつもこうやってるよ。俺下手なのか？ 216 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:52:40 ] ここでもやっぱり「こいつ下手そう」発言君↓ 217 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:53:34 ] どう考えても213はおかしいだろ 218 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:53:42 ] >>213 見るからに例外安全じゃないコードだな。 close前に例外飛んだらout もしRAIIだから大丈夫だとしたら逆にcloseを明示的に書いているのがダサい。 219 名前：213 mailto:sage [2006/09/01(金) 00:54:12 ] >>217 どこが？ 220 名前：213 mailto:sage [2006/09/01(金) 00:55:14 ] >>218 あー、俺やっぱり下手だわ。 意味さっぱりわかんね。 221 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:56:35 ] >>218 エラーコードでいちいちエラーチェックするより、例外使ったほうがいいという例じゃないの？ 222 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:00:20 ] >208-210 派生例外クラスじゃなくて、handleException を多態にするという意味では? void handleException ( Exception& e ); // 共通の処理 void handleException ( BarException& e ); // BarExceptionだけの処理 try{ 　//FooException,BarException,BazExceptionが発生する可能性あり } catch( Exception e ){ 　handleException( e ); } 223 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:07:01 ] >>221 エラーチェックの話なら, 例外版は適切にRAIIとかfinally相当でリソースの後始末をするべき。 これだと例外を使うとリソースをリークするという話にしか見えん。 まともに例外を扱えないやつが例外を書くと危険極まりない。 下手糞の例外は下手糞のgotoよりはるかに凶悪 224 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:07:31 ] >>220-221 resA の open に成功して、resB の open に成功した場合、 resA のリソースが開放されないので例外安全にならない。 スコープ抜けたら勝手に開放される(RAII)のであれば わざわざ close 呼んでるのが冗長。 225 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:11:43 ] >下手糞の例外は下手糞のgotoよりはるかに凶悪 まったくもってごもっとも。 つーか正直なところどんだけやってもC++の例外を使いこなす自信が持てん。 226 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:11:45 ] >>224 たぶん主張内容から推察するに × resBのopenに成功 ○ resBのopenに失敗 だな。 主張内容は完全に同意。 227 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:16:58 ] >>222 実際にやってみたか？引数のオーバロードは多態ではないから e が BarException でも共通の処理のほうに飛ぶんだが。 228 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:17:16 ] >>222 オブジェクト自身が振る舞いを知ってる場合が多態で 入り口(呼び出し側)でオーバーロード用意して 振り分けしちゃうのは多態とは言わないと思ってました。 実際のところどうなんでしょう？ >>226 ご指摘の通り。しかも223氏が本質的な発言先にしちゃってるし。 もう俺寝た方が良さそう。 229 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:23:53 ] >>228 お休み、よい夢をー。 230 名前：213 mailto:sage [2006/09/01(金) 03:26:07 ] あー、それは当然catch内でやる。213はtry{}の例。 231 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 03:41:27 ] catch内でリソースの開放処理をするのも上手くない。 その時点でcloseなどの解体処理が正常時と異常時の二箇所に分散するということが確定するから。 エラー処理を一箇所でやるための例外でその処理が分散したら本末転倒。 そんなんするならgotoでエラー処理するほうが開放処理が一箇所にまとまる分マシとさえ言える。 結局資源開放するならC++ならRAIIが定石(他言語ならfinally) 232 名前：231 mailto:sage [2006/09/01(金) 03:54:18 ] あと、resB->open()時に発生した例外と hoge(),huga()で発生した例外で開放するリソースが変わるからさらに面倒だな。 open時だとresAのみ、それ以外だとresA,resBを開放する必要がある。 こんなのを手動で開放処理書いてたら俺は間違いなくどこかでミスる自信がある。 233 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 03:58:32 ] > 間違いなくどこかでミスる自信がある うん、間違いなくミスってるよｗ resA->open()時に例外が発生する事象を見逃してる。 このケースだと資源の解放はいらない。 234 名前：231 mailto:sage [2006/09/01(金) 04:02:32 ] うへぇ、本当だ。やっぱりミスってたかー... うーん、こういう解体処理はRAIIに任せなきゃ駄目だなマジで 235 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 04:03:46 ] つまり例外は使うなってことでFA? 236 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 04:05:09 ] >>231 例外が有効な例を教えてくれ 237 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 04:07:57 ] こっちで。 例外処理 pc8.2ch.net/test/read.cgi/tech/1142667446/ 238 名前：231 mailto:sage [2006/09/01(金) 04:12:41 ] >>236 >>213のケースをRAIIで書くと有効な例になるんじゃね？ try {     Resource resA(a->getResource());     Resource resB(b->getResource());      resA->hoge();     resB->fuga(); }catch(){   /* エラー処理を記述 */ } どこにも開放処理はいらないし俺がミスる心配もない 239 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 06:58:19 ] ミスる心配が無いって気分いいよな 240 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 07:11:51 ] >>238 それだと、resA, resBに特化したエラー処理が書けないよ 241 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 07:57:56 ] COMでIDispatchとか使わされる状態だと例外ないとやってらんね 242 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 08:53:43 ] エラー処理は ResA.hoge()、ResB.hoge() の返り値を switch-case なり if なりで判定して行う。 エラー処理と例外処理は別のものだよ。 243 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 10:41:22 ] >227 まぁ、>222のとおりだとそうなるけど。 catch(BarException e) を同様に作ってやればいいだけの話。 try{ 　//throws FooException,BarException,BazException } catch( BarException be ){ 　handleException( be ); } catch( Exception e ){ 　handleException( e ); } 244 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 11:37:27 ] 以降、例外関連はこっちで。 例外処理 pc8.2ch.net/test/read.cgi/tech/1142667446/ 245 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 13:07:27 ] これJavaの話？ 246 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 22:39:05 ] >>240 try { 　　Resource resA(a->getResource()); 　　Resource resB(b->getResource()); 　　try { 　　　　resA->hoge(); 　　} catch(){ 　　　　// resA に特化したエラー処理 　　　　// 処理を途中で止めるなら throw 　　} 　　try { 　　　　resB->fuga(); 　　} catch(){ 　　　　// resB に特化したエラー処理 　　} }catch(){ /* エラー処理を記述 */ } >>242 > エラー処理と例外処理は別のものだよ。 はぁ？ 247 名前：デフォルトの名無しさん mailto:sage [2006/09/01(金) 23:11:38 ] はぁ？ 248 名前：デフォルトの名無しさん mailto:sage [2006/09/02(土) 01:35:16 ] エラー処理と例外処理は別のものだろ。 それは間違いない。例外＝エラーじゃない。 ファイルストリームの中でバッファ溢れを検知して例外投げて 捕まえた奴がフラッシュしてバッファ空にして処理続行、 別に変わった使い方じゃないし、どこにもエラーは無い。 249 名前：デフォルトの名無しさん mailto:sage [2006/09/02(土) 05:35:40 ] はじめてtry-cacheがあって本当に良かったと思ったのはつい最近。 javascriptでregexpを評価する時に 食わせる正規表現が不完全な時に出るエラーメッセージをcacheして潰した時。 つーのも、無計画に追加していった自分用リンク集がいい加減肥大化して 目的のもの見つけるのが面倒くさくなってきたんで regexpインクリメンタルサーチを搭載してみたんだけど 入力途中の、正しい正規表現かどうかかわからん文字列を 本当に正規表現として正しいのかどうか調べてから食わせるより とりあえず食わせてみた後にエラー潰したほうが遥かに楽だったという話 250 名前：デフォルトの名無しさん mailto:sage [2006/09/02(土) 06:39:17 ] >>249敢えて何も言うまい(´・ω・`) 251 名前：デフォルトの名無しさん mailto:sage [2006/09/02(土) 10:38:15 ] >>249 2回間違えるあたり単なるスペルミスではなさそうだな。 252 名前：デフォルトの名無しさん mailto:sage [2006/09/02(土) 12:53:01 ] キャッシュ？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef