[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 11/21 21:39 / Filesize : 247 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

VB.NET質問スレ (Part17)



1 名前:最凶VB厨房 mailto:sage [2006/08/11(金) 19:40:44 ]
[前スレ]VB.NET質問スレ (Part16)
pc8.2ch.net/test/read.cgi/tech/1149432480/

862 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 17:57:38 ]
>>861
StackTraceって>>858みたいな使い方できたっけだぜ?

あと、例外の処理は関数の責務というより、
プロジェクト全体、退いては会社などのポリシーによって統一されなければいけないもんだぜ。
派遣がたまに来て、ルールぶち壊す奴がいるが、
そういうのが一番アスホールになるんだべ?

863 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:12:51 ]
スタックトレースでほぼ見えるだろ。
全メソッドでそういうことするのはおかしいて言ってる。
.NETでの例外処理において、やってはいけないこと、に挙げられてるよ。


864 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:14:35 ]
>>863
誰が言ってるの?
何をやってはいけないの?

865 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:17:33 ]
全メソッドでException型でキャッチして再スローするようなこと。


866 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:20:44 ]
>>865
まあ、まずはソースだ。
MSが言ってるレベルだと信頼は無いからな。

大体、本当にやってはいけないことなら、コーディングレベルでエラーが出るだろ。


867 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:23:09 ]
ソース出せ
ああ、ベンダのいうことは信用できないから駄目だよ

868 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:24:05 ]
だったら.NETなんかつかわなけりゃいい

869 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:26:53 ]
例外のスローや再スローが非常に高コストなのは
常識だと思ってた。
ていうか、全メソッドでやるなら例外なんて仕組みいらんだろ。

870 名前:デフォルトの名無しさん [2006/10/18(水) 18:27:56 ]
EUCコードのデータを取り込んで表示させるにはどうすればよろしいのでしょうか?
そのままだと文字化けしてしまうのでSJISやUTFに変換しないと駄目でしょうか?



871 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:30:48 ]
ゲームでも作ってるんじゃないからコストなんか考えない。
バグが出ない、修正やカスタマイズがし易い、何か起こったとき直ぐに場所と原因が突きとめられる。
VB.NETで重要なのはこの3点だけ。

メモリが足りないのなら、メモリを積め。
遅いのなら、速いマシンを買え。

コストをシビアに考えるなら、VBなんか使わねーよ

872 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:30:58 ]
独立したスレッド等、処理を断続させる場合だけ、TryCatch
それ以外は、イベントハンドルとして処理。
これでいいだろ。

全メソッドでTryCatchなんてありえん。
初心者と技術のない職場のポリシーだけだ。



873 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:32:33 ]
>>871
それは単なるお前の自論だろ。


874 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:34:56 ]
>>873
IBMで教わった持論なんだがな。

875 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:36:02 ]
>>872
VB6のときは、イベント内のみにしかイベントハンドルを書かなかった口か?

876 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:38:51 ]
>>871
try〜catch〜finally〜内にバグがないとも限らない。
一元管理されるほうが、どう考えても効率いいし、バグが入りにくい。


877 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:40:02 ]
>>875
どう解釈しても意味不明だわな




878 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:44:20 ]
グダグダだな

879 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:46:36 ]
>>876
それはリスクポリシーの取り方だろ。
可読性の良いコードなら、catchやfinallyにバグが入り込む可能性は低い。
try内の問題が直ぐ判別できるから尚良い。

つーか、1メソッド、try〜catch〜finally〜含めても、
コードなんて20行も無いだろ?
catch内でも2〜3行なもんだろ?

880 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:47:08 ]
>>870
ここ読んでみたら?
ttp://dobon.net/vb/bbs/log3-4/1733.html



881 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 18:59:37 ]
お前有り得ない例外処理が反乱してるのを見たことないのか?

882 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:02:07 ]
>>881
無いね。
危ない例外は完全に殺してしまうし、
例外処理用にかなりこなれた関数も用意してるし。

883 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:10:21 ]
>>879
>コードなんて20行も無いだろ?
そうとは限らないだろ・・・どんだけ規模の小さいプログラムよ

884 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:11:34 ]
>>882
例外処理用に関数用意するなら、

最初から、ThreadExceptionイベントをハンドルして処理するだけでいいだろが

885 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:11:57 ]
>>883
1メソッド20行にも納められないのかよ。
どんだけ、汚いプログラムだよw

886 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:13:34 ]
>>884
趣旨が間違えているぞ。
運用に入ってからでも、ユーザーに気付かれず、
簡単に且つ素早く、エラーを起こしている箇所を特定しなければならないんだよ。

887 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:21:09 ]
>>879
>可読性の良いコードなら、catchやfinallyにバグが入り込む可能性は低い。
可読性は関係ないだろー
そこにバグがあると動作中のバグがどこにあるのかわからないことだってある。

888 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:25:03 ]
>>886
ThreadExceptionイベントで、
簡単に且つ素早く、エラーを起こしている箇所を特定できない状況をおしえてくれよ。

そもそもユーザーに気づかれない機能って何だよ。


889 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:26:55 ]
つか、スタックトレースを知らないってオチはないよな…


890 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:29:05 ]
.NET the final frontier.



891 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:31:54 ]
ThreadExceptionイベントで取れるわけだが・・・

892 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:38:11 ]
スタックトレースは厳密な経路ではない

893 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:42:18 ]
結局スタックとレース以外でcatchやfinallyは必要ないってオチですか?




894 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:45:00 ]
厳密な経路ってどんなん?
スタックトレースでは困るほど異なるもんなのか?


895 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:46:30 ]
そんなに場所特定したいならpbd付けとけ

896 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:47:08 ]
pdbだorz

897 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:47:53 ]
全メソッドでExceptionをキャッチ
経路の詳細情報をログ出力
そして再スローって
具体的にどんなコードになるんだ?


898 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:48:36 ]
スタックトレースってReleaseとDebugで挙動が異なるんじゃなかった?

899 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:50:41 ]
ソースのパスと行番号が出るだけ

900 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:50:49 ]
>>897
あまりいじりたくないコードになりそうだなw




901 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:51:24 ]
どこで例外が起きてるかそこまでして知らなくてはならないということは、
どうしようもないパゲッティで、どっちらけなコードではないか?


902 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:56:15 ]
>>901
お前らのコードよりも見やすい自信はある。
但し、サブルーチンが多いので、奥まで入れてグチュグチュする必要はある。

903 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 19:59:15 ]
スパゲッティじゃんw

904 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:13:17 ]
>>903
なんだ?
お前はサブルーチンのないコードが正当だというのか?
普通、コメントや改行、宣言を除いて、メソッドで処理に書ける行は5〜10行だぞ。
それ以上長くなると、可読性のないコードになる。
それだと、一つ一つサブルーチンにしてしまった方が良い。


905 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:16:00 ]
厳密もなにも、メソッド内で得れる経路情報なんて、
ThreadExceptionイベントでも取得できますよ。

それにさ、メソッドごとに特化した例外処理なんて入れてたら、
それこそ、そこにまでバグが潜む可能性があるんだからさ、
決まり文句かくならThreadExceptionイベントで十分だろ。


906 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:18:54 ]
>>904
つまり、10000ステップのソースなら、
1000〜2000メソッドあるってことですね。

907 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:20:29 ]
>>906
つ共通化

908 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:20:59 ]
>>905
メソッド内の例外処理は全て同じ。

909 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:22:52 ]
行数が少ないほど可読性が高いと思ってるのか?
DBの正規化でも、同じことが言えるだろ?

簡単な電卓プログラムじゃないんだから。


910 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:25:12 ]
>>907
お前のステップ換算は共通化する前のソースなのか?

>>908
全て同じなのに、ThreadExceptionイベントでダメな理由は何?





911 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:26:39 ]
ま、どうでもいいけど、
たった1000ステップに100も200もメソッド作らんね。

912 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:28:34 ]
>>909
1024*768で、
一画面に収まるコードはマナーだろ。

>>910
関数化も共通化も終えての行数だ。
ステップ数じゃない。

913 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:32:15 ]
ここにいる連中はステップ数と行数の違いもわからないのか?

マジあきれた。

914 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:34:12 ]
一度その全て同じなコードを書いてみてくれ。


915 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:36:10 ]
その全て同じなコードが処理行数5〜10行の全てのメソッドに書いてあるのか?

916 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:39:04 ]
で、関数の数はいくつなん?

917 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:39:36 ]
>>915
全て同じなコード自体が1行のコードだがな

918 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:40:38 ]
>>916
言うほど多くない。
クラス設計できてたら大したことにならない。

919 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:42:32 ]
練習で作った電卓プログラムですってオチですか?


920 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:43:02 ]
なんかわけのわからんことで揉めてるな
正直、例外のトラップを一元化した方が好ましいって言う奴初めて見たよw
それ実践を踏まえて言ってるんだろうか。

それって、それこそN-BASICの時代のON ERROR GOTOじゃんw

いやそれならまだしも、その飛び先で例外オブジェクトをパースしないといけないんでしょ?
それじゃSDKのウィンドウプロシージャと一緒じゃんw



921 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:44:24 ]
俺の場合は最終的な例外処理はThreadExceptionとかの共通ハンドラ。
まあここではユーザ用メッセージの表示とログ出力位だが。
メインなロジック部分は、ロジックの最上位辺りで自動補捉してログ出力、必要に応じてラップその他の処理。
あとは個別に特に例外処理が必要な箇所だけキャッチして処理。

他の部分はキャッチなし。finallyのみ。


922 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:45:10 ]
ちゃんと.NETが提供してる機能があるんだから、
何も知らない初心者はすっこんでろ。


923 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:48:28 ]
一行でどうやって再スローまでやるんだ?
しかもExceptionをキャッチしてだろ?
全然特化してない例外処理しか出来ないのに、
これじゃ各メソッドでやる意味があるように見えないんだが…

924 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:56:43 ]
>>923
つ関数

925 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 20:59:12 ]
単にThreadExceptionのハンドラを使ったことがないから、よく知らないってオチでいいよ。


926 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 21:01:20 ]
Application.ThreadExceptionイベントスゲーウヒョー

927 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 21:01:52 ]
>>924
>>884

928 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 21:27:44 ]
           ∩_ 
          〈〈〈 ヽ
          〈⊃   }
  ∩___∩  |   |
  | ノ      ヽ !   !
  /  ●   ● |  /
  |    ( _●_)  ミ/ < 次いこうぜ〜
 彡、   |∪|  /
/ __  ヽノ /
(___)   /

929 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 21:41:33 ]
そんな事したらスタックトレース消えるだろうがよ。
それに変なメソッドが例外のソースになるだろうがよ。

お、ひょっとしてそれでスタックトレースみれてないのか?
もし仮にそうだとしたらあほとしかいいようがない。

930 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 21:45:39 ]
>>920個別に処理してしまう例外はその場でキャッチするに決まってるだろ。
それ以外の例外だよ、まとめて処理するのは。
全メソッドでExceptionをキャッチするなら、
同じようにパースが必要になるんじゃないのか?



931 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 21:56:07 ]
もういいよ、既に決着はついてる。

932 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:01:34 ]
>>920はあふぉうだから相手にするな

933 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:03:46 ]
>>930
それ以外って何だよw

いや、@ITの記事にも書いてあった気がするが
想定外の例外が起きた場合の「保険」的な意義は大いにあるよ。

それにそういう想定外の例外の場合、いきなりあの無愛想なデフォの例外のダイアログが
出るより、別の何らかの表示をするようにした方がユーザーの心証もいいしね。

逆に言えばそれ以外の価値は一切認められないよ。

934 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:08:21 ]
だからさー
ThreadExceptionイベントをハンドルすればいいだけだろ。

どうしてもメソッド内で処理しないと困る例外だけ try〜catch〜を使えばOKだろ。


935 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:09:52 ]
そういうのを逆立ちした発想っていうんだよ

936 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:12:02 ]
じゃあさ、最初から出てる全メソッドでExceptionキャッチってなんなのよ?
全部想定されるException型なのかよ。
全メソッドで想定されるExceptionがあるのかよ。
多くのメソッドでは想定される例外なんてそうないだろに。

937 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:13:37 ]
誰も全ての例外を最上位でやるなんていってないのに。

938 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:18:18 ]
まずさ、
メソッド内で取得できるExceptionは、
Application.ThreadExceptionのイベントハンドラでも取得できるというのは解ってるよな?

それで、わざわざ全メソッドに同じ例外処理の内容を書く理由はあるのか?



939 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:20:30 ]
ネタかと思ったけど本当にパーなのね。
だから>>930の「それ以外」って何のこと?w
具体的に挙げてみ。

つーか、だいたい何のために構造化例外処理なんてものを導入した経緯が
あると思ってるんだ

940 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:25:15 ]
「それ以外」
同じ例外処理のことだろ?



941 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:31:17 ]
IDないからぐずぐずになってるスレ


942 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:35:48 ]
コテハンつけるかもしくはアンカー打ってくれ。
何がなんだかさっぱりわからんw

943 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:35:52 ]
だめだわけわかんね。
構造化例外は、全メソッドでException型をキャッチすることで何か意味があるとでも?
個別に処理してしまえる例外以外を具体的にって
いったいどういえと。

944 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:37:02 ]
全メソッドで全例外をキャッチするなら
構造化例外なんていらん

945 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:40:05 ]
>>939お前が個別に処理しなきゃならない例外を具体的に挙げろよ。
それで処理してしまえない残ったもの全部だよ。

パーとかいってんだからお前があげろ
ついでに全メソッドで例外をキャッチして再スローするメリットもな

946 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:42:21 ]
あと、個別にキャッチしてする例外処理は全部同じ処理だぜ

947 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:45:13 ]
意地張って、表現の仕方にケチつけるくらいしか出来ないんだよ。
実際まともな解答がひとつも無い。

948 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:47:14 ]
>>934
>>934
>>934


949 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:49:06 ]
まあ愚か者は経験からしか学ばないわけでw
いや経験から本当に学んでいるかどうかも怪しいわけだが。

構造化例外処理の意義がどこにあるか?
それはThreadExceptionで一元的にトラップするように書いた自分のコードを
一年後にメンテしてみればたぶんよくわかるよ。

まあそれでわからなきゃ本当にパーだわ。

950 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:50:43 ]
>>949
根拠も具体例もないただの自論だな




951 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:53:54 ]
誰も全て一元化するなんていってない

いいから全メソッドでExceptionをキャッチして以下省略のメリット書けや。
構造化例外はそのためにあるんだろ?
おかけでメンテも楽になるんだろ?
お前の経験でこんなメリットてのを書けよ


952 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:53:58 ]
>>950
トンデモさんにとってはアインシュタインの相対性理論も「根拠のないただの持論」らしいからなw
まともなプログラマやソフトウエア工学の学者で構造化例外処理を否定してる奴が
一人でもいたら教えてくれよ。

953 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:54:56 ]
ついに構造化例外処理を否定してることになったぜ。

954 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:56:23 ]
>>951
何か勘違いしているようだが、メソッド全体をTry〜ブロックに入れろ、
なんてトンデモをいっている奴は一人もいないと思うぞw

ただThreadExceptionイベントなんぞには保険的な意味合いしかないと
言っている奴がいるだけだ。

955 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:58:03 ]
>>952
お前は馬鹿か?

「全メソッドに同じ例外処理の内容を書く理由はあるのか? 」
この質問に、根拠のないただの持論で誰が納得するんだ?

メリデリをしっかり挙げてくれないとお話にならないだろ。


956 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 22:58:39 ]
>>953
自分の言っていることがわからないんだから病膏肓だねw
ThreadExceptionイベントなるものに保険以上の意味を認めるってことは
構造化例外処理を否定しているってことだ。

だから>>930の「それ以外」とは何かと聞いているだろう

957 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 23:01:56 ]
例外トラップとかはAOPしたいんだけど、catchの方はEventに投げるとしてもFinallyの方がやり様がないよね

958 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 23:02:02 ]
構造化例外処理といいながら、全メソッドに関数呼ぶ同じ1行ですか?ワラカシテクレルゼ

959 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 23:05:04 ]
>ThreadExceptionイベントなるものに保険以上の意味を認めるってことは
>構造化例外処理を否定しているってことだ。

面白いこと言うんだな。

Try-Catch構文だと、例外を正しくトラップできないケースは多々あるのに対して、
ThreadExceptionイベントは確実にトラップできる。 これは事実だ。

960 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 23:06:08 ]
>>955
プログラミングの基本からわかってないようだから言っても無駄だと思うけど、
仮に例外処理に「共通の処理」があるとしたら普通はそれ自体をメソッドにして
「明示的に」それを呼び出すコードを書くんだよ。

馬鹿は自分の記憶力があてにならない、という事実すら忘れるんだろうけど
コードを書いたときには「ここで例外が発生した場合を俺は想定しているぞ。その場合は
ThreadExceptionのハンドラに飛んで・・・・・・」と思っていてもそんなことは
人は忘れてしまう。

まして最初からそんなこと知らない他人はどうなるんだよ。



961 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 23:07:07 ]
だからさ、ユーザ用のつうちをThreadExceptionでやるだけだろが。
それだけで構造化例外処理の意味がなくなるのかよ。そんなに言うならお前の言葉で構造化例外のメリットを説明しろ。
ついでにThreadExceptionを上記の様に使うだけで
構造化例外を否定してることになるという具体的にな説明もな

962 名前:デフォルトの名無しさん mailto:sage [2006/10/18(水) 23:07:22 ]
なんでもかんでもCatchする方がよっぽど構造化例外処理を否定してると思うけどな






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<247KB

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