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

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2009/03/22(日) 06:57:59
前スレ
http://pc11.2ch.net/test/read.cgi/tech/1198822420/
0425デフォルトの名無しさん2009/05/21(木) 18:00:57
メソッドチェーンして使うような関数のエラーは例外で返して
ほしいかなぁ。
チェーンの途中でnullとか出力されるとヌルポが怖くて使えん。
0426デフォルトの名無しさん2009/05/21(木) 18:20:06
>>422
>>424は関数の内部の実装なんか知ったこっちゃねぇ、ただ
APIとしてユーザに公開される関数に関しては例外を投げるな、
エラーコードで戻せ、と言いたいんじゃ無いのかな。

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

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

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

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

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

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

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

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

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

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

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

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

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

やっぱりおれは例外使うけど
0453デフォルトの名無しさん2009/05/22(金) 10:19:04
自演じゃなかったのか？
0454デフォルトの名無しさん2009/05/22(金) 10:58:24
>>450
その前に、OOの話をしていて唐突に例外に話題が移る時点で。
0455デフォルトの名無しさん2009/05/22(金) 11:04:28
>>443
> どのメソッドがどんな例外をthrowするかなんてIDEがチェックできるだろ。
> そのためのthrows句だ、カス。
どの関数が throwするかじゃなくて、実行時にどの関数が実行されるかが問題。
0456デフォルトの名無しさん2009/05/22(金) 11:27:08
>>454
インスタンスが分からない人たちだからしょうがないね
0457デフォルトの名無しさん2009/05/22(金) 11:39:29
例外自体は悪くないが例外の実装が悪いので使えない
言語境界とかOS境界を越えて同じバイナリを使うのが困難すぎる
0458デフォルトの名無しさん2009/05/22(金) 12:02:34
なるほどね。

メソッドの実装を変更すると、投げられる可能性のある例外が変わる。
その例外を垂れ流せばインタフェースが変わってしまう。

でも、インタフェースが実装に依存するのはよくないから、
全ての例外をメソッドの内部でcatchしておくべき。

問題は、何かのミスで例外が外に漏れ出したりしないことを保証できるかどうか。
0459デフォルトの名無しさん2009/05/22(金) 12:15:48
>>458
何番のレス？
＞問題は、何かのミスで例外が外に漏れ出したりしないことを保証できるかどうか。
全ての例外を握りつぶすことは簡単、例外が発生したらreturn falseするのも簡単
} catch {
return false;
}
0460デフォルトの名無しさん2009/05/22(金) 12:27:15
>>459
処理系にもよるだろうけど、
中でスレッド起こしてたら、例外は別ルート通っていってキャッチできなくね？
0461デフォルトの名無しさん2009/05/22(金) 12:36:13
>>460
例外ってスレッドで独立してないか？
呼び出したルーチンに例外は漏れんと思うが
0462デフォルトの名無しさん2009/05/22(金) 12:45:31
結局>>388だな
0463デフォルトの名無しさん2009/05/22(金) 12:51:05
>>461
だから、処理系によると書いた。
少なくとも、g++では別スレッドからの例外はキャッチできずにプログラム自体が落ちた経験がある。
0464デフォルトの名無しさん2009/05/22(金) 12:51:09
で、例外とオブジェクト指向に何の関係があるの？
0465デフォルトの名無しさん2009/05/22(金) 12:57:12
>>464
メソッドがどんな例外を投げるか
っていうのは、インタフェースに関わることで、
インタフェースはオブジェクト指向の本質と言っても過言ではない。
0466デフォルトの名無しさん2009/05/22(金) 12:57:16
とりあえず、例外云々で議論する人たちは、オブジェクト指向どころか、構造化すら解ってない予感
0467デフォルトの名無しさん2009/05/22(金) 13:00:50
>>465
> インタフェースはオブジェクト指向の本質と言っても過言ではない。

なぜか、オマイのことだけは信用していい気がした。
0468デフォルトの名無しさん2009/05/22(金) 13:05:03
インターフェースってjavaのあれ？
C++やLispでCLOSを使ってると出て来ないよね？
0469デフォルトの名無しさん2009/05/22(金) 13:10:35
>>419
例外は例外的な事態が発生した時に発生させるものなので、
基本的にパフォーマンスは問題にならない。
もそパフォーマンスが問題になるほど頻繁に例外を発生させてるのなら、
例外の使い方が間違ってる。
0470デフォルトの名無しさん2009/05/22(金) 13:18:00
んなこたない
0471デフォルトの名無しさん2009/05/22(金) 13:24:35
文字列パースする為のメソッドなんかは、例外を吐くやつと、
速度重視で真偽値を返す奴との2通り用意してある事が多いでしょ。
0472デフォルトの名無しさん2009/05/22(金) 13:31:39
エラーが予測できる場所は if を使うべき
予測可能な例外って意味わかんないよ！
0473デフォルトの名無しさん2009/05/22(金) 13:38:00
>>472
いや、ifを書くとコードがごちゃごちゃするから、例外でまとめてキャッチするという手段を使うと良い場合もあるんだよ。
0474デフォルトの名無しさん2009/05/22(金) 13:39:46
エラーが発生→スレッドを殺す→新しいスレッドを作成
ってやった方がシンプルで安全な場合もある。
0475デフォルトの名無しさん2009/05/22(金) 13:56:53
>>473
ifが嫌ならswitchを使うといいwww
0476デフォルトの名無しさん2009/05/22(金) 13:58:43
>>475
根本解決になってない
0477デフォルトの名無しさん2009/05/22(金) 13:59:07
>>473
ま、キレイに書きたい気持ちは分かるけど…
本当にそれは例外じゃないとだめなの？
0478デフォルトの名無しさん2009/05/22(金) 14:03:52
>>477
お前に言われたくないが、
ErlangスタイルでC++とかでプログラミングするなら例外を使うときれいにまとまるな。
0479デフォルトの名無しさん2009/05/22(金) 14:11:19
広い範囲をtry{}で囲むとすっきりするが
例外がどこから飛んできたのかわかりにくくなる。

全然関係ない場所から偶然同じ型の例外が飛んできたら嫌じゃん
0480デフォルトの名無しさん2009/05/22(金) 14:23:07
>>479
必要があれば部分的に例外処理、荒くも細かくもできる
0481デフォルトの名無しさん2009/05/22(金) 14:23:23
>>479
例外が投げられた場所に応じた細かい対応を記述したいの
なら狭い範囲を囲めばいいじゃん。
広い範囲を囲むのは、その範囲内で投げられた例外に対して
同じ処理で対応出来る時。

所詮書き分けで対応出来る話でしょ。
0482デフォルトの名無しさん2009/05/22(金) 14:34:35
例外処理は、BASICのON ERROR GOTOを思い出してダサいなぁと思ってしまう
0483デフォルトの名無しさん2009/05/22(金) 14:39:53
コンストラクタの中から
BadArgumentExceptionとかするのはいかがなものか。
0484デフォルトの名無しさん2009/05/22(金) 14:41:50
>>482
そりゃ例外云々じゃなくてGOTOだからダサいんでしょ。
関数呼び出しのたびにIF書いてGOTO飛ばしたらもっとダサくなる。

>>483
素敵だと思うけど。
0485デフォルトの名無しさん2009/05/22(金) 14:56:42
>>484
ON ERROR GOTOは、GOTOと書かれてるからダサいんじゃない、エラー処理の本質がGOTOだって事を嫌でも思い知らされるからダサいんだよ
0486デフォルトの名無しさん2009/05/22(金) 15:06:02
ttp://msdn.microsoft.com/ja-jp/library/cc440185.aspx
オブジェクト プロバイダのガイダンス

例外を、単なる別のエラー処理技法のように扱ってはいけません。
エラーコードを返したり、グローバル変数の設定したりすることと同レベルだと思ってはいけません。
例外は、それを取り巻くコードの構造と意味を、根底から覆します。
例外は、プログラムの実行時セマンティックを一時的に繋ぎ変え、通常実行しているコードを迂回し、
こういう状況でなければ決して実行されないコードを動作させます。
例外は、エラー状態を認知させ、プログラムの死という罰則を用いてその状態を改めようとします。

このように、例外には単純なエラー処理を超えた特性があります。
これらの特性を必要としない、理解しない、あるいは文書化したくないなら、例外をスローしてはいけません。
例外以外のエラー処理技法を探してください。

スローすることに決めたなら、すべての因果関係を理解してください。
あなたの設計が、あなたのコードを使用する他のユーザーに、潜在的に多大な影響を与えることを承知していてください。
例外はインターフェイス契約の一部なのです。
どの種類の例外をインターフェイスからスローするのか、どのような場合に例外をスローするのか、
なぜスローするのか、これらを完全に文書化しなければなりません。
そして、その文書を例外仕様として、コードの中に記述することを十分考えてください。
0487デフォルトの名無しさん2009/05/22(金) 15:10:19
ON ERROR GOTOは紛れも無く例外処理だろwww
0488デフォルトの名無しさん2009/05/22(金) 15:11:54
>例外はインターフェイス契約の一部なのです。

ですね
わかります
0489デフォルトの名無しさん2009/05/22(金) 15:12:14
例外を使うコードは見づらくてよくない。
エラーの発生した処理と遠く離れたところにcatchがあるのは
現代のスパゲティプログラムといえるね
0490デフォルトの名無しさん2009/05/22(金) 15:16:01
>>486
こうも書いてあるね

>例外をスローすべき十分な理由があるなら、進んでその例外をスローして、
>それを文書化すればよいのです。例外をスローするのが当然の場面で、
>例外のスローを回避する方法を発明する必要はありません。
0491デフォルトの名無しさん2009/05/22(金) 15:47:41
例外をスローするのが当然の場面、って何だろうな。

仕様、仕様とあるように、例外を投げる仕様と、
投げなくて問題があれば単にnullを返す仕様。

どちらが当然か、という話になるのか？
そういう話じゃないのか？
0492デフォルトの名無しさん2009/05/22(金) 16:03:49
いいこと思いついた
引数で「例外ファクトリ」を指定する仕様にすればスローするのが当然だよね
0493デフォルトの名無しさん2009/05/22(金) 18:13:48
ああーやっぱり明確な仕様の記述なしに例外投げんなでＦＡか
まあ、そうじゃねぇと邪魔でしょうがねぇよな
0494デフォルトの名無しさん2009/05/22(金) 19:39:15
ドキュメントをまったく書くつもりのない俺は例外を書く資格なしということで
このスレの例外議論を終了したいと思います。2009年5月22日（金）
0495デフォルトの名無しさん2009/05/22(金) 19:52:02
C++が最強
0496デフォルトの名無しさん2009/05/22(金) 21:35:47
ABIがCな時点でCが最強なんだよタコ
0497デフォルトの名無しさん2009/05/22(金) 21:37:45
お前はABIが何か分かってないな
0498デフォルトの名無しさん2009/05/22(金) 21:37:49
C++にしても基本はCだからね
0499デフォルトの名無しさん2009/05/22(金) 21:55:13
なんだか、継続の代わりに例外を使ってる人が居そう。
0500デフォルトの名無しさん2009/05/22(金) 22:03:55
え？ｗ
0501デフォルトの名無しさん2009/05/22(金) 22:10:28
失敗を恐れているんじゃねぇよ。
エラーになるかもなんていっていたら何もできやしない。
俺はエラー処理なんて一度も書いたことねぇ。
やれるって信じたら絶対できる。
0502デフォルトの名無しさん2009/05/22(金) 22:20:20
最適化と同じで、エラーを気にしだすときりがない気はする
0503デフォルトの名無しさん2009/05/22(金) 22:30:20
例外処理ってビミョーだよな。

投げる側では「ある条件のとき例外を投げる」
として、普通におもっくそ想定を置いている。
例外でもなんでもない。
ゼロで割る？　ファイルがない？　数値化できる文字列じゃない？

んなもん事前に調べれ。
0504デフォルトの名無しさん2009/05/22(金) 23:18:44
例外なんて投げたことないな。
そんな機能があったことも忘れたよw
0505デフォルトの名無しさん2009/05/22(金) 23:30:10
>>503
ファイルの存在を確認してから
開くまでの間に消されるかもしれないじゃないか。
そんなのどうやって事前に調べるんだよ
0506デフォルトの名無しさん2009/05/22(金) 23:31:26
ライブラリが下手に例外投げる仕様だと
受け手がいなくて死んだりする
リンクのミスとかで他の不具合も出る
投げないにこしたことない
0507デフォルトの名無しさん2009/05/22(金) 23:32:39
落ちなければいいってわけでもないが
0508デフォルトの名無しさん2009/05/22(金) 23:37:36
>>505
それは「ファイルを消すな」という問題じゃね？
プログラムが責任を持つのはせいぜい、
プログラム内での排他処理でよくね？

OSレベルのことで困れば、
オチてプログラム呼び出し側で責任取らせればよくね？

呼び出し元の事情を気にするのは、
よくない設計じゃね？
0509デフォルトの名無しさん2009/05/22(金) 23:45:48
次のfreadがしける程度だろ？
0510デフォルトの名無しさん2009/05/23(土) 03:37:44
例外イラネとか言ってるやつのどれだけが、
malloc()の返り値のNULLチェックをやっているのやら。
0511デフォルトの名無しさん2009/05/23(土) 04:13:00
>>503
> ゼロで割る？　ファイルがない？　数値化できる文字列じゃない？
> んなもん事前に調べれ。

文句言うまえに、そんな糞パラメータ送ったおまえが調べろよ。
0512デフォルトの名無しさん2009/05/23(土) 04:47:38
例外は"スタックを調整してデータを積んでGOTOしてるだけ"なので

a();
v = f();
b();
c(v);

一見正しくみえるが、f()が例外を飛ばすのを忘れていると
例外自体は他でキャッチするのでテストはキチンと失敗するにも関わらず
f()が失敗したのに誤ってa()したり、誤ってb()しなかったりする

OO的に

Any f() {
if (!hoge()) reterun new Error("Can't hoge!");
return fuga();
}

のように正常な経路でメッセージを戻せばその種の不整合問題は発生しづらい
エラー処理を忘れたらc(v)の内部でとまるので原因はすぐわかる
実際はc(v)内部で引数のチェックくらいするからエラーを記録して何もしないという選択もできる

例外投げたらそこで終了だよ
0513デフォルトの名無しさん2009/05/23(土) 05:33:56
>>512
Javaの場合、トラップするべき例外をトラップしていなければ
コンパイラがそれを指摘してくれますが何か？

返り値でエラーコードを返す場合にはそうはいきませんなあ。

で、君はmalloc()するたびにちゃんとNULLチェックしてるの？
0514デフォルトの名無しさん2009/05/23(土) 05:38:46
>>512
おまえ、本当にマか？

> Any f() {
> if (!hoge()) reterun new Error("Can't hoge!");
> return fuga();
> }

コンパイラさんからreterunって何？って叱られるぞw

> のように正常な経路でメッセージを戻せばその種の不整合問題は発生しづらい

f()の返り値がおかしいかどうかちゃんとチェックしていなければ、
原因をトレースするのが厄介になるぞ。c(v)が悪いのかf()が悪いのかa()が悪いのか
ワケワカラン状態になるのがオチだ。
例外を使えばちゃんとスタック保存してくれているから原因は一目瞭然。

> 実際はc(v)内部で引数のチェックくらいするからエラーを記録して何もしないという選択もできる

空のハンドラ渡すのと何が違うの？
0515デフォルトの名無しさん2009/05/23(土) 05:41:47
>>512
>f()が例外を飛ばすのを忘れていると
処理に失敗したのにも関わらず例外を投げ忘れたf()は、返値
として一体何を返すの?

>if (!hoge()) reterun new Error("Can't hoge!");

ここでエラーを返すか例外を投げるか、それだけの違いでは。
if (!hoge())をチェックすべきことが分かっているか否か、大切
なのはその事であって、この事に気づいていればエラーを返す
とか例外投げるとかは単に実装の違いに過ぎないと思う。

>f()が失敗したのに誤ってa()したり、
関数の呼び出し順が間違っているのでは。a()の実行の前提と
してf()の成功が必要なら、f()の後にa()呼ぶでしょ。
これは例外とか返値云々とは無関係な、因果律の問題。

>誤ってb()しなかったりする
何のためにensureやfinallyがあると思っているんだ。

>c(v)の内部でとまるので原因はすぐわかる
止まったときには結局例外が投げられるんじゃない?

>Any f() {

言語にもよるけど、静的型付けの言語の場合には結果と
詳細なエラー情報を共に返値で返すとなると返値の型や
セマンティクスで悩むことは少なく無いと思う。
Anyですか。そうですか。
0516デフォルトの名無しさん2009/05/23(土) 05:50:56
>>515
> 言語にもよるけど、静的型付けの言語の場合には結果と
> 詳細なエラー情報を共に返値で返すとなると返値の型や
> セマンティクスで悩むことは少なく無いと思う。

そうそう。存在しないキーでハッシュマップ引いた時に
例外を投げずにNullを返しちゃったりしたら、
ハッシュマップで対応する値がNullだったのか、
ハッシュマップで対応する値がなかったのか、
判別つかないんだよな。
その判別をするための特殊なクラスをつくると、
とたんに返り値の型が問題になる。
Objectとかにしたら、今度は使う側でナローキャスト
してやらなきゃならなくなって静的型のメリットがなくなるし。
0517デフォルトの名無しさん2009/05/23(土) 06:27:10
>>515
f()が例外を返すことを書いた時は覚えていた
その例外は別の階層でトラップされるから正しい記述である
が翌日忘れてあるいは別人が修正したとするそんな感じのバグが生まれる話
言語仕様が関数が例外を投げると宣言することを強制しても
例外を戻す関数が他にあれば紛れてしまうでしょ

a()の位置が違うのは分かってワザとそこに書いたの
v=f()のところにエラー処理の記述があればレビューの時に誰か気付くんだよ
0518デフォルトの名無しさん2009/05/23(土) 07:33:56
>>516
C#の場合だが例外を発生させないためにTryGetValueがある。
bool result = dictionary.TryGetValue(key,out val);
キーのない値をひくのは通常処理の場合が往々にしてあるからこれも必要と思う
0519デフォルトの名無しさん2009/05/23(土) 08:49:42
お前らが言ってるのは、例外処理以前の話じゃん

「ドキュメントやコメントをちゃんと書きやがれ」

って次元の問題じゃん
0520デフォルトの名無しさん2009/05/23(土) 09:50:34
Cだったら戻り値の意味書くぐらいでいいのに例外だと説明すんのがめんどくさいんだよね
0521デフォルトの名無しさん2009/05/23(土) 09:52:13
GetValueとFindがあればいいだけの話。
GetValueは例外、FindはNo Such Keyを表す何かを返す。
0522デフォルトの名無しさん2009/05/23(土) 10:23:07
どんどん話が低脳者の会話になっていってるな
もうオブジェクト指向が無くなれとか言う問題じゃなくなってるwww
0523デフォルトの名無しさん2009/05/23(土) 10:40:46
>>518
outがなければ例外を投げればいいじゃない(ｷﾘｯ
0524デフォルトの名無しさん2009/05/23(土) 11:30:50
例外は>>486で結論出てるのにな…
ライブラリが例外を返すようなコードを書くな。書くならそのリスクを覚悟しろってことだ
0525デフォルトの名無しさん2009/05/23(土) 12:49:19
>>524
486のリンク先は言ってることが良く分からない。
内容が有益であるのなら、だれか要点をまとめてくれない?

# だらだらした文書である上、罰則だの精神とかの妙な単語が頻出していて
# 頭のおかしなやつが書いたようにしか見えなかった…
# (ソースのインデントの仕方も一番ダメだと思っているスタイルだったし…)
■ このスレッドは過去ログ倉庫に格納されています