VB.NET質問スレ (Part17)

おい、みんな〜

例外キャッチは、Exception型で全部済ませてるよな？

キャッチなんてごく一部しか書かない。

まじで？
とりあえず全部のコードTryCatchで括って、Exceptionで受ける
ってみんな書いてないのか・・・

ごく一部ってのは全プログラムコードで見たらごく一部のコードという意味だよ。
全部のコードってどういう意味？
一番外側的な（あるいはそれに近い）意味ならそういう感じになるのは分かるが。
あとは個別に処理してしまう場合だけな。

俺は基本的に関数は全てtry〜catch〜finally〜。
JavaやPHP5では基本だろ。

あほだね

全ての関数で基本的にcatchも書くって、
そのcatch内でいったい何をしてるんよ？
finallyでいったい何してるんよ？
# まあ finallyの方はまだいいにしても

想定できない例外はこれでキャッチすればいいんでないの？
http://www.atmarkit.co.jp/fdotnet/dotnettips/320appexception/appexception.html

うんそうだね

>>845
なんだよ、これ。
こんなの思いつかねーよ

思いつくんじゃない、見つけるんだ。

びっくりさせるなよー
ThreadExceptionイベントをハンドルして処理してるのは俺だけかと思ったよ、まじで。
お前らの常識はほんとあてにならないな。

どんな常識かね？

>>844
catchで例外の詳細をログに落としてる。
finallyでオブジェクトの開放。

普通じゃん。

全メソッドで個別にログ出力かよ

でエラー状況はどうやって返してるんだ？
まさか再スローじゃないだろ？

>>852
全メソッドで個別ログを取らないと、詳細なログにならない。
いらなくなったら、ログるレベルを変えるだけ。

>>853
最上位がしっかり処理してるなら、
別に再スローでも良いんじゃない？

全メソッドでログ出力＆再スローってありえんだろ。

catchされたもののログだろ？
全然ありえるじゃん。

メソッド呼び出しの深さ分同じ例外のログ出力するんかい！
あと詳細ログ出せないっていうけど、
各メソッドで出すことでどれだけ詳細度があげられるんだ？
全メソッドでそれはありえんだろ。

>>857
どのイベントから呼び出したどのメソッドの中にあるメソッドの…
と、経路と部位の特定が簡単になるのが、ダメなのか？
ユーザーが言うバグにも早く対応ができるし。

つーか、何に対してそこまでの否定を？

すいません、VB.NET(2003)で質問です。
フォーム上にTextBoxが20個配置されていて、
例えばそれらにTB_1, TB_2, …TB_20 というようなコントロール名がついているとします。
これらのTextBoxをForループなどで一律に処理する方法はあるでしょうか。

具体的なイメージとしては
For i = 1 To 20
　［"TB_" & CStr(i) をコントロール名に持つTextBox］.Text = data(i)
Next
みたいなことができるといいのですが。
要はコントロール名からオブジェクトを取得できればいいわけなんですけれど。

>>859
Controlsプロパティでググれ

>>858
StackTraceとか。
そもそもその例外を外に出すのか、内部で処理するのか、どちらが正しいってのはその関数の責務の問題になるし。

>>861
StackTraceって>>858みたいな使い方できたっけだぜ？

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

スタックトレースでほぼ見えるだろ。
全メソッドでそういうことするのはおかしいて言ってる。
.NETでの例外処理において、やってはいけないこと、に挙げられてるよ。

>>863
誰が言ってるの？
何をやってはいけないの？

全メソッドでException型でキャッチして再スローするようなこと。

>>865
まあ、まずはソースだ。
MSが言ってるレベルだと信頼は無いからな。

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

ソース出せ
ああ、ベンダのいうことは信用できないから駄目だよ

だったら.NETなんかつかわなけりゃいい

例外のスローや再スローが非常に高コストなのは
常識だと思ってた。
ていうか、全メソッドでやるなら例外なんて仕組みいらんだろ。

EUCコードのデータを取り込んで表示させるにはどうすればよろしいのでしょうか？
そのままだと文字化けしてしまうのでSJISやUTFに変換しないと駄目でしょうか？

ゲームでも作ってるんじゃないからコストなんか考えない。
バグが出ない、修正やカスタマイズがし易い、何か起こったとき直ぐに場所と原因が突きとめられる。
VB.NETで重要なのはこの3点だけ。

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

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

独立したスレッド等、処理を断続させる場合だけ、TryCatch
それ以外は、イベントハンドルとして処理。
これでいいだろ。

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

>>871
それは単なるお前の自論だろ。

>>873
IBMで教わった持論なんだがな。

>>872
VB6のときは、イベント内のみにしかイベントハンドルを書かなかった口か？

>>871
try〜catch〜finally〜内にバグがないとも限らない。
一元管理されるほうが、どう考えても効率いいし、バグが入りにくい。

>>875
どう解釈しても意味不明だわな

グダグダだな

>>876
それはリスクポリシーの取り方だろ。
可読性の良いコードなら、catchやfinallyにバグが入り込む可能性は低い。
try内の問題が直ぐ判別できるから尚良い。

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

>>870
ここ読んでみたら？
ttp://dobon.net/vb/bbs/log3-4/1733.html

お前有り得ない例外処理が反乱してるのを見たことないのか？

>>881
無いね。
危ない例外は完全に殺してしまうし、
例外処理用にかなりこなれた関数も用意してるし。

>>879
>コードなんて20行も無いだろ？
そうとは限らないだろ・・・どんだけ規模の小さいプログラムよ

>>882
例外処理用に関数用意するなら、

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

>>883
1メソッド20行にも納められないのかよ。
どんだけ、汚いプログラムだよｗ

>>884
趣旨が間違えているぞ。
運用に入ってからでも、ユーザーに気付かれず、
簡単に且つ素早く、エラーを起こしている箇所を特定しなければならないんだよ。

>>879
>可読性の良いコードなら、catchやfinallyにバグが入り込む可能性は低い。
可読性は関係ないだろー
そこにバグがあると動作中のバグがどこにあるのかわからないことだってある。

>>886
ThreadExceptionイベントで、
簡単に且つ素早く、エラーを起こしている箇所を特定できない状況をおしえてくれよ。

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

つか、スタックトレースを知らないってオチはないよな…

.NET the final frontier.

ThreadExceptionイベントで取れるわけだが・・・

スタックトレースは厳密な経路ではない

結局スタックとレース以外でcatchやfinallyは必要ないってオチですか？

厳密な経路ってどんなん？
スタックトレースでは困るほど異なるもんなのか？

そんなに場所特定したいならpbd付けとけ

pdbだorz

全メソッドでExceptionをキャッチ
経路の詳細情報をログ出力
そして再スローって
具体的にどんなコードになるんだ？

スタックトレースってReleaseとDebugで挙動が異なるんじゃなかった？

ソースのパスと行番号が出るだけ

>>897
あまりいじりたくないコードになりそうだなｗ

どこで例外が起きてるかそこまでして知らなくてはならないということは、
どうしようもないパゲッティで、どっちらけなコードではないか?

>>901
お前らのコードよりも見やすい自信はある。
但し、サブルーチンが多いので、奥まで入れてグチュグチュする必要はある。

スパゲッティじゃんw

>>903
なんだ？
お前はサブルーチンのないコードが正当だというのか？
普通、コメントや改行、宣言を除いて、メソッドで処理に書ける行は5〜10行だぞ。
それ以上長くなると、可読性のないコードになる。
それだと、一つ一つサブルーチンにしてしまった方が良い。

厳密もなにも、メソッド内で得れる経路情報なんて、
ThreadExceptionイベントでも取得できますよ。

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

>>904
つまり、10000ステップのソースなら、
1000〜2000メソッドあるってことですね。

>>906
つ共通化

>>905
メソッド内の例外処理は全て同じ。

行数が少ないほど可読性が高いと思ってるのか？
DBの正規化でも、同じことが言えるだろ？

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

>>907
お前のステップ換算は共通化する前のソースなのか？

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

ま、どうでもいいけど、
たった１０００ステップに１００も２００もメソッド作らんね。

>>909
1024*768で、
一画面に収まるコードはマナーだろ。

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

ここにいる連中はステップ数と行数の違いもわからないのか？

マジあきれた。

一度その全て同じなコードを書いてみてくれ。

その全て同じなコードが処理行数5〜10行の全てのメソッドに書いてあるのか？

で、関数の数はいくつなん?

>>915
全て同じなコード自体が1行のコードだがな

>>916
言うほど多くない。
クラス設計できてたら大したことにならない。

練習で作った電卓プログラムですってオチですか？

なんかわけのわからんことで揉めてるな
正直、例外のトラップを一元化した方が好ましいって言う奴初めて見たよw
それ実践を踏まえて言ってるんだろうか。

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

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

俺の場合は最終的な例外処理はThreadExceptionとかの共通ハンドラ。
まあここではユーザ用メッセージの表示とログ出力位だが。
メインなロジック部分は、ロジックの最上位辺りで自動補捉してログ出力、必要に応じてラップその他の処理。
あとは個別に特に例外処理が必要な箇所だけキャッチして処理。

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

ちゃんと.NETが提供してる機能があるんだから、
何も知らない初心者はすっこんでろ。

一行でどうやって再スローまでやるんだ？
しかもExceptionをキャッチしてだろ？
全然特化してない例外処理しか出来ないのに、
これじゃ各メソッドでやる意味があるように見えないんだが…

>>923
つ関数

単にThreadExceptionのハンドラを使ったことがないから、よく知らないってオチでいいよ。

Application.ThreadExceptionイベントスゲーウヒョー

>>924
>>884

　　　　　　　　　 　∩＿　
　　　　　　　　　　〈〈〈　ヽ
　　　　　　　　　 〈⊃　　 }
　　∩＿＿＿∩　 |　　 |
　　| ノ　　　　　 ヽ !　　 !
　 /　　●　　　● |　　/
　 |　　　　( _●_)　 ミ／ ＜ 次いこうぜ〜
　彡､　　　|∪|　　／
/　＿＿　 ヽノ　/
(＿＿＿）　　　/

そんな事したらスタックトレース消えるだろうがよ。
それに変なメソッドが例外のソースになるだろうがよ。

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

>>920個別に処理してしまう例外はその場でキャッチするに決まってるだろ。
それ以外の例外だよ、まとめて処理するのは。
全メソッドでExceptionをキャッチするなら、
同じようにパースが必要になるんじゃないのか？

もういいよ、既に決着はついてる。

>>920はあふぉうだから相手にするな

>>930
それ以外って何だよw

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

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

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

だからさー
ThreadExceptionイベントをハンドルすればいいだけだろ。

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

そういうのを逆立ちした発想っていうんだよ

じゃあさ、最初から出てる全メソッドでExceptionキャッチってなんなのよ？
全部想定されるException型なのかよ。
全メソッドで想定されるExceptionがあるのかよ。
多くのメソッドでは想定される例外なんてそうないだろに。

誰も全ての例外を最上位でやるなんていってないのに。

まずさ、
メソッド内で取得できるExceptionは、
Application.ThreadExceptionのイベントハンドラでも取得できるというのは解ってるよな？

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

ネタかと思ったけど本当にパーなのね。
だから>>930の「それ以外」って何のこと？w
具体的に挙げてみ。

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

「それ以外」
同じ例外処理のことだろ？

IDないからぐずぐずになってるスレ

コテハンつけるかもしくはアンカー打ってくれ。
何がなんだかさっぱりわからんｗ

だめだわけわかんね。
構造化例外は、全メソッドでException型をキャッチすることで何か意味があるとでも？
個別に処理してしまえる例外以外を具体的にって
いったいどういえと。

全メソッドで全例外をキャッチするなら
構造化例外なんていらん

>>939お前が個別に処理しなきゃならない例外を具体的に挙げろよ。
それで処理してしまえない残ったもの全部だよ。

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

あと、個別にキャッチしてする例外処理は全部同じ処理だぜ

意地張って、表現の仕方にケチつけるくらいしか出来ないんだよ。
実際まともな解答がひとつも無い。

>>934
>>934
>>934

まあ愚か者は経験からしか学ばないわけでw
いや経験から本当に学んでいるかどうかも怪しいわけだが。

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

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

>>949
根拠も具体例もないただの自論だな

誰も全て一元化するなんていってない

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

>>950
トンデモさんにとってはアインシュタインの相対性理論も「根拠のないただの持論」らしいからなw
まともなプログラマやソフトウエア工学の学者で構造化例外処理を否定してる奴が
一人でもいたら教えてくれよ。

ついに構造化例外処理を否定してることになったぜ。

>>951
何か勘違いしているようだが、メソッド全体をTry〜ブロックに入れろ、
なんてトンデモをいっている奴は一人もいないと思うぞw

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

>>952
お前は馬鹿か？

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

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

>>953
自分の言っていることがわからないんだから病膏肓だねw
ThreadExceptionイベントなるものに保険以上の意味を認めるってことは
構造化例外処理を否定しているってことだ。

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

例外トラップとかはAOPしたいんだけど、catchの方はEventに投げるとしてもFinallyの方がやり様がないよね

構造化例外処理といいながら、全メソッドに関数呼ぶ同じ１行ですか？ﾜﾗｶｼﾃｸﾚﾙｾﾞ

>ThreadExceptionイベントなるものに保険以上の意味を認めるってことは
>構造化例外処理を否定しているってことだ。

面白いこと言うんだな。

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

>>955
プログラミングの基本からわかってないようだから言っても無駄だと思うけど、
仮に例外処理に「共通の処理」があるとしたら普通はそれ自体をメソッドにして
「明示的に」それを呼び出すコードを書くんだよ。

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

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

だからさ、ユーザ用のつうちをThreadExceptionでやるだけだろが。
それだけで構造化例外処理の意味がなくなるのかよ。そんなに言うならお前の言葉で構造化例外のメリットを説明しろ。
ついでにThreadExceptionを上記の様に使うだけで
構造化例外を否定してることになるという具体的にな説明もな

なんでもかんでもCatchする方がよっぽど構造化例外処理を否定してると思うけどな

>>960
> コードを書いたときには「ここで例外が発生した場合を俺は想定しているぞ。その場合は
> ThreadExceptionのハンドラに飛んで・・・・・・」と思っていてもそんなことは
> 人は忘れてしまう。
アホ。例外を想定してないからThreadExceptionで受けるんだよ。
想定してたらそれに応じた型の例外をその場でCatchして処理するわ。
おまえ全然分かってないな。

全メソッドで共通なら全部書かなくても同じだろ
ついでだが、業務で開発とかだとまとめて一ヶ所で処理はやむをえないことも多い

>>963
何を的外れな仮の話をしているんだい？
それが全メソッドに同じ例外処理を書く理由ですか？

↑アンカーまちがい、>>960な

>>963
それなら俺が>>933で書いたことを否定する理由はないはずだが。
ま、馬鹿は自分の言っていることも人の言っていることもよくわからないんだねw

見事に質問が埋もれてるな。

>>870
System.Text 名前空間の Encoding クラスを使って、
Encoding.GetString 使ったり StreamReader の引数に渡したりする。

全メソッドにtrycatch書くってひとは、悪いけどトリップつけてくんない?
どれが馬鹿か分からなくって困るから

>>969
だからそんな奴は最初からいません。

>>840
>>842
>>851

>>960
> コードを書いたときには「ここで例外が発生した場合を俺は想定しているぞ。その場合は
> ThreadExceptionのハンドラに飛んで・・・・・・」と思っていてもそんなことは
> 人は忘れてしまう。
意識する必要がないだろ。良く考えろよ。
全く同じ決まった処理なら、ThreadExceptionのイベントハンドラとして一箇所に書いてあるのだから意識不要。
そのメソッド内でどうしても必要なものだけ書けばいいんだから、よっぽど効率いいだろ？

>>972
話の通じない馬鹿だなw
もういいよ一生やってな別に止めないし

全メソッドにtrycatch書くってひとは、
具体的なメリデリが書けません。自論です。　ってオチですな。

要は全メソッドでCatchしないと正体不明の例外が処理できなかった時代の
手法をそのまま引きずってるだけじゃないの？
FrameWorkがそんなことしなくてもいいように設計されてるのに。

>>973
安心しろ、誰にも通じてない。

いや、書いてはある。
ただ君に理解できないだけだ。
そういえばトンデモさんの常套句もそうだ。

アインタインは間違っているに違いない！
この俺様に理解できないのだから！

せめて１人くらいには通じる話をしてくださいです〜

>>977お前もう痛すぎるから

関係ないけど、相対性理論の間違いは日本人によって正されつつある。
http://www.ni.bekkoame.ne.jp/tsuneizumi/
これくらいは解ってていってるんだろ？

あなたにアインタイン

AOPが一般化してるときになに一転だ。
全メソッドに同じ処理を書くべしって

だからtry〜catchを前メソッドに書くのが良いんだよ。
ThreadException知らないやつでも、明示的に処理してるのが分かる。
チームプログラミングは、上のレベルであわせるのではなく、
VB.NET初めて3日のヤツでも理解できるように書いてやるんだよ。
いつまでも一定レベル以上の人間じゃないとメンテできないソースなんて、
人的コストが掛かりすぎてたまらんわ。
お前らみたいな優秀なやつらをメンテなんかで使いたくないんだぜ？

つまり低レベルの人間に合わせた低レベルの手法ということですね。納得。

明確にだめだと言われてるやりかただけどな。
て言うか、未だにその共通処理でなにやるのか分からん

>>984
お前らみたいに視野の狭い連中は物作りさせるしか使い道が無いのよ。

まあいかにもVB6でOn Error ResumeNextとか多用してたような奴が
考えそうなことなんだけどね

＼　　 　　　　 　　　　　　　�U　　　　　　 　 /
　 ＼　　　　　 　　　　　　　�U　　　　　 　 /
　　　　　　　　　　　　　／￣￣　ヽ,
　　　　　　　　　　　　/　　　　　 　 ',　　　　　　/　　 　　＿/＼／＼/＼／|＿
　　　 ＼　　　 ﾉ//, {0}　 /¨`ヽ　{0}　,ﾐヽ　 　 /　 　　 ＼　　 　　　　　　 　／
　　　　　＼ ／　く　ｌ　　 ヽ._.ノ　　　', ゝ　＼　　　 　　 ＜　　 バーカ 　　＞
　　　　　／ ／⌒　ﾘ　　　｀ー'′　　 ' ⌒＼ ＼　　　　／　 　　　　　　　　＼
　　　　　(　　￣￣⌒　　　　　　　　　　⌒￣　＿)　　　￣|／＼/＼/＼/￣
　　　　　　｀￣￣｀ヽ　　　　　　　　　　　/´￣
　　　　　　　　　　　|　　　　　　　　　 　 | 　
　　−−− ‐　　　ﾉ　 　　　　　　　　　｜
　　　　　　　　　 ／ 　　　　　　　 　 　ﾉ　　　　　　　 −−−−
　　　　　　　　 /　　　　　　　　 　　∠＿
　　−−　　　|　 　 f＼　　　　　　ﾉ　 　 ￣`丶.
　　　　　　　　| 　 　|　　ヽ＿＿ﾉー─-- ､_ 　　）　　　　−　_
.　　　　　　　 ｜　　| 　 　　　　　　　　　/　　/
　　　　 　　 　｜　｜　　　　　　　　　　,'　　/
　　　　／ 　／　　ﾉ　　　　　　　　　 　| 　 ,'　　　 ＼
　　　　　　/ 　 ／ 　 　　　　　　　　 　|　 /　　　　　 ＼
　　　／_ノ　／　 　 　 　　　　　　　　,ﾉ　〈 　 　 　 　 　 ＼
　　　　(　 〈　　　　　　　　　　　　 　ヽ.__　＼　　　　　　　　＼
　　　　　ヽ.＿>　　　　　　　　　　　　　　＼__)

　　　　　　　　　 ／ 　　　　　　　 　 　ﾉ　　　　　　　 −−−−
　　　　　　　　 /　　　　　　　　 　　∠＿
　　−−　　　|　 　 f＼　　　　　　ﾉ　 　 ￣`丶.
　　　　　　　　| 　 　|　　ヽ＿＿ﾉー─-- ､_ 　　）　　　　−　_
.　　　　　　　 ｜　　| 　 　　　　　　　　　/　　/

>>983
だから、お前が言ってるのは、自論と、職場の規約や都合だけだろ・・・

お前ら、俺の言うことはアインシユタインの言うことだぞ
理解できないやつはトンデモなんだぞ

>>990
俺の職場のルールが正しければ、お前らが何て言おうと関係ない。
俺の会社はお前らみたいな零細とは違うんだからなｑｑ

とりあえずきっかけを作った>>838が悪いってことで終わりにしようぜ。スレも終わるし。
誰か次スレプリーズ。