VB.NET質問スレ (Part ..
[2ch|▼Menu]
910:デフォルトの名無しさん
06/10/18 20:25:12
>>907
お前のステップ換算は共通化する前のソースなのか?

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



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

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

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

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

マジあきれた。

914:デフォルトの名無しさん
06/10/18 20:34:12
一度その全て同じなコードを書いてみてくれ。


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

916:デフォルトの名無しさん
06/10/18 20:39:04
で、関数の数はいくつなん?

917:デフォルトの名無しさん
06/10/18 20:39:36
>>915
全て同じなコード自体が1行のコードだがな

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

919:デフォルトの名無しさん
06/10/18 20:42:32
練習で作った電卓プログラムですってオチですか?


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

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

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

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

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


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


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

924:デフォルトの名無しさん
06/10/18 20:56:43
>>923
つ関数

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


926:デフォルトの名無しさん
06/10/18 21:01:20
Application.ThreadExceptionイベントスゲーウヒョー

927:デフォルトの名無しさん
06/10/18 21:01:52
>>924
>>884

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

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

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

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

931:デフォルトの名無しさん
06/10/18 21:56:07
もういいよ、既に決着はついてる。

932:デフォルトの名無しさん
06/10/18 22:01:34
>>920はあふぉうだから相手にするな

933:デフォルトの名無しさん
06/10/18 22:03:46
>>930
それ以外って何だよw

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

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

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

934:デフォルトの名無しさん
06/10/18 22:08:21
だからさー
ThreadExceptionイベントをハンドルすればいいだけだろ。

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


935:デフォルトの名無しさん
06/10/18 22:09:52
そういうのを逆立ちした発想っていうんだよ

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

937:デフォルトの名無しさん
06/10/18 22:13:37
誰も全ての例外を最上位でやるなんていってないのに。

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

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



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

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

940:デフォルトの名無しさん
06/10/18 22:25:15
「それ以外」
同じ例外処理のことだろ?

941:デフォルトの名無しさん
06/10/18 22:31:17
IDないからぐずぐずになってるスレ


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

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

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

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

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

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

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

948:デフォルトの名無しさん
06/10/18 22:47:14
>>934
>>934
>>934


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

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

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

950:デフォルトの名無しさん
06/10/18 22:50:43
>>949
根拠も具体例もないただの自論だな


951:デフォルトの名無しさん
06/10/18 22:53:54
誰も全て一元化するなんていってない

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


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

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

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

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

955:デフォルトの名無しさん
06/10/18 22:58:03
>>952
お前は馬鹿か?

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

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


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

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

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

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

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

面白いこと言うんだな。

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

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

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

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

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

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

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

964:デフォルトの名無しさん
06/10/18 23:11:09
全メソッドで共通なら全部書かなくても同じだろ
ついでだが、業務で開発とかだとまとめて一ヶ所で処理はやむをえないことも多い

965:デフォルトの名無しさん
06/10/18 23:11:47
>>963
何を的外れな仮の話をしているんだい?
それが全メソッドに同じ例外処理を書く理由ですか?

966:デフォルトの名無しさん
06/10/18 23:12:24
↑アンカーまちがい、>>960

967:デフォルトの名無しさん
06/10/18 23:12:49
>>963
それなら俺が>>933で書いたことを否定する理由はないはずだが。
ま、馬鹿は自分の言っていることも人の言っていることもよくわからないんだねw

968:デフォルトの名無しさん
06/10/18 23:13:22
見事に質問が埋もれてるな。

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

969:デフォルトの名無しさん
06/10/18 23:13:50
全メソッドにtrycatch書くってひとは、悪いけどトリップつけてくんない?
どれが馬鹿か分からなくって困るから


970:デフォルトの名無しさん
06/10/18 23:15:17
>>969
だからそんな奴は最初からいません。


971:デフォルトの名無しさん
06/10/18 23:17:18
>>840
>>842
>>851


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


973:デフォルトの名無しさん
06/10/18 23:21:10
>>972
話の通じない馬鹿だなw
もういいよ一生やってな別に止めないし

974:デフォルトの名無しさん
06/10/18 23:23:17
全メソッドにtrycatch書くってひとは、
具体的なメリデリが書けません。自論です。 ってオチですな。

975:デフォルトの名無しさん
06/10/18 23:25:53
要は全メソッドでCatchしないと正体不明の例外が処理できなかった時代の
手法をそのまま引きずってるだけじゃないの?
FrameWorkがそんなことしなくてもいいように設計されてるのに。

976:デフォルトの名無しさん
06/10/18 23:26:02
>>973
安心しろ、誰にも通じてない。


977:デフォルトの名無しさん
06/10/18 23:26:03
いや、書いてはある。
ただ君に理解できないだけだ。
そういえばトンデモさんの常套句もそうだ。

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


978:デフォルトの名無しさん
06/10/18 23:27:14
せめて1人くらいには通じる話をしてくださいです〜

979:デフォルトの名無しさん
06/10/18 23:29:03
>>977お前もう痛すぎるから

980:デフォルトの名無しさん
06/10/18 23:34:57
関係ないけど、相対性理論の間違いは日本人によって正されつつある。
URLリンク(www.ni.bekkoame.ne.jp)
これくらいは解ってていってるんだろ?

981:デフォルトの名無しさん
06/10/18 23:35:26
あなたにアインタイン

982:デフォルトの名無しさん
06/10/18 23:36:20
AOPが一般化してるときになに一転だ。
全メソッドに同じ処理を書くべしって

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

984:デフォルトの名無しさん
06/10/18 23:42:16
つまり低レベルの人間に合わせた低レベルの手法ということですね。納得。

985:デフォルトの名無しさん
06/10/18 23:45:21
明確にだめだと言われてるやりかただけどな。
て言うか、未だにその共通処理でなにやるのか分からん


986:985
06/10/18 23:46:37
>>984
お前らみたいに視野の狭い連中は物作りさせるしか使い道が無いのよ。

987:デフォルトの名無しさん
06/10/18 23:50:23
まあいかにもVB6でOn Error ResumeNextとか多用してたような奴が
考えそうなことなんだけどね

988:983
06/10/18 23:52:42

\               U         /
  \             U        /
             / ̄ ̄ ヽ,
            /        ',      /     _/\/\/\/|_
    \    ノ//, {0}  /¨`ヽ {0} ,ミヽ    /     \           /
     \ / く l   ヽ._.ノ   ', ゝ \       <   バーカ   >
     / /⌒ リ   `ー'′   ' ⌒\ \    /          \
     (   ̄ ̄⌒          ⌒ ̄ _)    ̄|/\/\/\/ ̄
      ` ̄ ̄`ヽ           /´ ̄
           |            |  
  −−− ‐   ノ           |
          /            ノ        −−−−
         /           ∠_
  −−   |    f\      ノ     ̄`丶.
        |    |  ヽ__ノー─-- 、_   )    − _
.        |  |            /  /
         | |          ,'  /
    /  /  ノ           |   ,'    \
      /   /             |  /      \
   /_ノ /              ,ノ 〈           \
    (  〈              ヽ.__ \        \
     ヽ._>              \__)




989:989
06/10/18 23:53:30
          /            ノ        −−−−
         /           ∠_
  −−   |    f\      ノ     ̄`丶.
        |    |  ヽ__ノー─-- 、_   )    − _
.        |  |            /  /


990:デフォルトの名無しさん
06/10/18 23:54:26
>>983
だから、お前が言ってるのは、自論と、職場の規約や都合だけだろ・・・


991:デフォルトの名無しさん
06/10/18 23:56:52
お前ら、俺の言うことはアインシユタインの言うことだぞ
理解できないやつはトンデモなんだぞ

992:デフォルトの名無しさん
06/10/18 23:58:14
>>990
俺の職場のルールが正しければ、お前らが何て言おうと関係ない。
俺の会社はお前らみたいな零細とは違うんだからなqq

993:デフォルトの名無しさん
06/10/18 23:58:20
とりあえずきっかけを作った>>838が悪いってことで終わりにしようぜ。スレも終わるし。
誰か次スレプリーズ。

994:デフォルトの名無しさん
06/10/18 23:59:56
もう震度毛よ

995:デフォルトの名無しさん
06/10/19 00:01:33
素朴に疑問だ。ホントに全メソッドで全例外キャッチ?

996:838
06/10/19 00:06:33
盛り上がったなwww

997:デフォルトの名無しさん
06/10/19 00:15:45
100ならVB.NETはメソッド内でTry〜Catch〜Finally〜が正しい。

998:デフォルトの名無しさん
06/10/19 00:25:29
コレでまたひとつ新しいトリビアが誕生した

999:デフォルトの名無しさん
06/10/19 00:29:38
今更だけどメリデリって何ですか?

1000:デフォルトの名無しさん
06/10/19 00:29:42
1000なら伊東怜と生でセックスできる

1001:1001
Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。


最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

5183日前に更新/247 KB
担当:undef