06/10/15 22:30:31
>>798
以下のようなコードです。全部は書ききれませんので、次レスで。
Const N As Short = 4
Dim p(N) As Integer
Private Sub perm(ByRef i As Integer, ByVal e As PictureBox)
Dim g As Graphics = e.CreateGraphics()
Dim t As Integer
Dim j As Integer
If i < N Then
For j = i To N
t = p(i)
p(i) = p(j)
p(j) = t
perm(i + 1, Picture1)
t = p(i)
p(i) = p(j)
p(j) = t
Next j
Else
For j = 1 To N
Dim centuryFont As Font = New Font("century", 8, FontStyle.Regular)
Dim blackBrush As SolidBrush = New SolidBrush(Color.Black)
g.DrawString(p(j), centuryFont, blackBrush, p(j) * 20, j * Font.Height)
Next j
End If
End Sub
803:デフォルトの名無しさん
06/10/15 22:31:14
Private Sub Command1_Click(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs) Handles Command1.Click
Display(Picture1)
End Sub
Sub Display(ByVal e As PictureBox)
Dim g As Graphics = e.CreateGraphics()
Dim i As Integer
g.Clear(Color.White)
For i = 1 To N
p(i) = i
Next i
perm(1, Picture1)
End Sub
End Class
804:デフォルトの名無しさん
06/10/15 22:32:58
g.DrawString(p(j), centuryFont, blackBrush, p(j) * 20, j * Font.Height)
ここの座標設定は適当です。
とにかくここをどうやってするかが難しいのです。
805:デフォルトの名無しさん
06/10/15 22:58:51
まあ、色々突っ込み所満載なわけだが、とりあえずy座標に関して言えば
クラスメンバにy座標を持って、最初の再帰呼び出しの前でクリアして
1行描画したら1行分足せばいいんじゃないか。
あとx座標も変だぞ。それじゃ全部1234になっちまう。
806:デフォルトの名無しさん
06/10/15 23:02:57
>>805
そうです。だから座標は適当にしているだけなんです。
今までのVBのように
ｐ(i)を一つ一つ並べればきちんといくはずなんですが・・。
クリアというとつまりはどういうことなんでしょうか？
807:デフォルトの名無しさん
06/10/15 23:19:05
Dim p(N) As Integer の下に Dim y As Integer を追加
描画を g.DrawString(p(j), centuryFont, blackBrush, j * 8, y) に修正
その下の Next j の下に y += 12 を追加
Displayメソッドの perm(1, Picture1) の前に y = 0 を追加
808:デフォルトの名無しさん
06/10/15 23:22:44
>>805
y座標はうまくいきました。
ありがとうございます。
809:デフォルトの名無しさん
06/10/15 23:27:02
>>807
丁寧にありがとうございます。
perm(i + 1, Picture1)の前に
ｋ＝ｋ+1といれて
g.DrawString(p(j), centuryFont, blackBrush, j * 20, (k - 1) * 10)
とすればできました。x座標もできました。
たぶんあなたが教えてくれたものが正確だと思うので
そのように書き直させてもらいます。
810:デフォルトの名無しさん
06/10/15 23:27:22
っていうか、明らかに適性ないよ悪いけど。
もうコードのここがダメとかあそこを直せばいいという問題じゃなく、全てがダメ。
こんなの初学の学生が宿題で書いたコードとしても酷すぎる。
811:デフォルトの名無しさん
06/10/15 23:31:33
>>810
そうですか。
まあ、また気が向いたら教えてください。
812:デフォルトの名無しさん
06/10/15 23:46:46
クラスの動作確認の方法ってどうやってやるのですか？
ソリューションエクスプローラにクラス追加で下記のクラスを追加してF5を押しても確認が取れません。
よろしくお願いします。
Imports System
Imports System.Net
Imports System.Text
Public Class WebClientGet3
Shared Sub Main()
Dim wc As WebClient = New WebClient()
Dim data As byte() = wc.DownloadData("URLﾘﾝｸ(www.google.co.jp))
Dim enc As Encoding = Encoding.GetEncoding("Shift_JIS")
Dim html As String = enc.GetString(data)
Console.WriteLine(html)
End Sub
End Class
813:デフォルトの名無しさん
06/10/15 23:56:13
クラスの動作確認ってかなり意味不明だな。
取りあえず MSDN かヘルプドキュメントで /main コンパイラオプション の項目を調べれ
814:デフォルトの名無しさん
06/10/16 02:43:01
>>812
お前の作るクラスにはmainというメソッドがあるのか。
いやだな・・・
しかもクラス単位にmainというメソッドしかない作りなんだろ？
そんな作りはやめたほうがいい。
815:デフォルトの名無しさん
06/10/16 10:32:01
プログラムの仕組みでClassを使うやつは、
PGのセンスを疑うな。
クラスとオブジェクトの意味を理解してもらいたい。
816:デフォルトの名無しさん
06/10/16 11:31:15
VB2005でnkf32.DLLを使いたいのですがどのように記述すれば良いのでしょうか？
例えばGetNkfVersion関数を使うとして
Public Declare Function GetNkfVersion Lib "nkf32.dll" (ByVal verStr As String)
等と書いてみたのですが名前空間のステートメントが無効ですとエラーが表示されてしまいます。
817:デフォルトの名無しさん
06/10/16 12:05:41
クラスまたはモジュールのメンバになる位置に書く
818:デフォルトの名無しさん
06/10/16 13:54:36
今日、あるソースのコメント部分に、SpecialThanx ～～～～～～ と書いてるのを見つけた。
ここのスレタイがかいてあったので見に来てみた。
なるほどね。
819:デフォルトの名無しさん
06/10/16 14:37:11
>>817
ありがとうございました。
820:デフォルトの名無しさん
06/10/16 15:59:45
>>802
なんで引数のPictureBoxがeなん?
CreateGraphicsで作ったGraphicsで描いたら、画面重なったら消えるやん?
なんで描画コードを再帰で作るん? 計算だけ再帰にして描画は一発にすべきじゃないの?
そもそも再帰の必要あるの?
再帰とループの中でなんで何度もSolidBrush作るん?
GraphicsやSolidBushをDisposeしないの?
821:デフォルトの名無しさん
06/10/16 18:18:07
>>820
>>793にPG適性が無いから
822:デフォルトの名無しさん
06/10/16 20:23:21
ここで適性無しとか言われてキレたりするやついるけど、正直ほんとに
適性としか言えない何かがあるんだよ。適性無いのに業界入りするのは
自殺行為に等しいから、向いてないと感じたら職種替えたほうがいい。
うちに今年入った素人高卒が、いまバリバリにコーディングしてるその
そばで、情報系大卒３年選手が単なるテスターになってるのを目の当た
りしてほんとそう思うよ。
823:デフォルトの名無しさん
06/10/16 21:39:42
>>812
コンパイルしてエラーで出なければオｋでしょｗ
824:デフォルトの名無しさん
06/10/16 21:51:34
>>823
品質無視ならそれでもいいんじゃね？
その発想は、大概UIも一貫性がなかったり、仕様も捻くれてて直感的に使えないんだよな。
825:デフォルトの名無しさん
06/10/16 22:10:18
質問のしかたはともかく、質問者のレベルとか、適正や職種なんてこのスレとは無関係。
質問者にも理解できるような適切な解答をするべきだろ？
それができないで何を偉そうに威張ってるんだい？その辺のガキと変わらないぞ。
826:デフォルトの名無しさん
06/10/16 22:11:52
するべきって何だよそれ。。。
827:デフォルトの名無しさん
06/10/16 22:21:17
解答のしかたはともかく、解答者のレベルとか、適正や職種なんてこのス
レとは無関係。解答者にも理解できるような適切な質問をするべきだろ？
828:デフォルトの名無しさん
06/10/16 22:32:01
>>827
それだと、解答者も質問者とたいして変わらないのだから･･・と言ってるように聞こえる。
829:デフォルトの名無しさん
06/10/16 22:35:21
>>828
ま、知ってるか知らないかだけで、質問するやつも解答するやつも同レベルってことだ。
830:デフォルトの名無しさん
06/10/16 23:35:33
適切な回答も理解できないあほもいるんです＞＜
831:デフォルトの名無しさん
06/10/17 04:43:58
適切な質問も理解できないあほもいるんです＞＜
832:デフォルトの名無しさん
06/10/17 05:19:31
適切なスレも理解できないあほもいるんです＞＜
833:デフォルトの名無しさん
06/10/17 12:15:10
VB.NET2005 側で構造体を確保して、その確保したエリアを
VC.NETで作成したDLL側で操作したいんですが、一般的な手法
ってどんな感じになるんでしょうか？
例えば、VB.NET2005側で、構造体の配列を確保して、それを
DLL側でソートしたり、VB.NET2005側で確保したエリアに
DLL側でファイルからデータを読み込んで値をセットしたりと
いった事がやりたいんですが。
UNIX環境のCでしかプログラムを作ったことが無いので、
VB.NET2005と、VC.NETで作成したDLLの間のデータの受渡し方法や、
VB.NET2005側がどのような形でエリア(メモリ)を確保しているのかや、
VB.NET2005側の変数の型と、確保されたエリアの関係(サイズや、アドレス)や、
VB.NET2005側の変数の型と、確保されたエリアの内部コード(文字列型の場合)、
VB.NET2005側の構造体と、確保されたエリアの関係(サイズや、アドレス)等が
良く判りません。
かなり、抽象的な質問で申し訳ないのですが、これらに関する情報や、書籍など
ありましたら、紹介して頂けないでしょうか。
834:デフォルトの名無しさん
06/10/17 12:29:28
>>833
P/Invokeという単語をMSDNで調べるかググる。
835:833
06/10/17 14:05:50
>>834
THX。
マーシャリングとか、アンマネージとか、なにやら面妖なキーワードが
沢山出て来て、戸惑っています。
Windows(.NET環境)ってなんか凄いですね。
ともあれ、ようやく欲しい情報にたどり着くことができました。
ありがとうございます。
836:デフォルトの名無しさん
06/10/17 22:09:33
というかまず VC.NET という謎の存在を解決する必要があるな
837:デフォルトの名無しさん
06/10/17 23:02:43
.NET なんてただの飾りです
エロイ人には
838:デフォルトの名無しさん
06/10/18 00:33:57
おい、みんな～
例外キャッチは、Exception型で全部済ませてるよな？
839:デフォルトの名無しさん
06/10/18 00:49:16
キャッチなんてごく一部しか書かない。
840:デフォルトの名無しさん
06/10/18 00:59:14
まじで？
とりあえず全部のコードTryCatchで括って、Exceptionで受ける
ってみんな書いてないのか・・・
841:デフォルトの名無しさん
06/10/18 01:06:54
ごく一部ってのは全プログラムコードで見たらごく一部のコードという意味だよ。
全部のコードってどういう意味？
一番外側的な（あるいはそれに近い）意味ならそういう感じになるのは分かるが。
あとは個別に処理してしまう場合だけな。
842:デフォルトの名無しさん
06/10/18 01:48:14
俺は基本的に関数は全てtry～catch～finally～。
JavaやPHP5では基本だろ。
843:デフォルトの名無しさん
06/10/18 02:03:20
あほだね
844:デフォルトの名無しさん
06/10/18 02:05:24
全ての関数で基本的にcatchも書くって、
そのcatch内でいったい何をしてるんよ？
finallyでいったい何してるんよ？
# まあ finallyの方はまだいいにしても
845:デフォルトの名無しさん
06/10/18 02:14:46
想定できない例外はこれでキャッチすればいいんでないの？
URLﾘﾝｸ(www.atmarkit.co.jp)
846:デフォルトの名無しさん
06/10/18 02:21:40
うんそうだね
847:デフォルトの名無しさん
06/10/18 02:56:40
>>845
なんだよ、これ。
こんなの思いつかねーよ
848:デフォルトの名無しさん
06/10/18 03:42:47
思いつくんじゃない、見つけるんだ。
849:デフォルトの名無しさん
06/10/18 04:52:55
びっくりさせるなよー
ThreadExceptionイベントをハンドルして処理してるのは俺だけかと思ったよ、まじで。
お前らの常識はほんとあてにならないな。
850:デフォルトの名無しさん
06/10/18 07:57:17
どんな常識かね？
851:デフォルトの名無しさん
06/10/18 13:36:39
>>844
catchで例外の詳細をログに落としてる。
finallyでオブジェクトの開放。
普通じゃん。
852:デフォルトの名無しさん
06/10/18 13:52:48
全メソッドで個別にログ出力かよ
853:デフォルトの名無しさん
06/10/18 13:55:22
でエラー状況はどうやって返してるんだ？
まさか再スローじゃないだろ？
854:デフォルトの名無しさん
06/10/18 14:25:18
>>852
全メソッドで個別ログを取らないと、詳細なログにならない。
いらなくなったら、ログるレベルを変えるだけ。
>>853
最上位がしっかり処理してるなら、
別に再スローでも良いんじゃない？
855:デフォルトの名無しさん
06/10/18 15:08:48
全メソッドでログ出力＆再スローってありえんだろ。
856:デフォルトの名無しさん
06/10/18 15:11:28
catchされたもののログだろ？
全然ありえるじゃん。
857:デフォルトの名無しさん
06/10/18 15:13:17
メソッド呼び出しの深さ分同じ例外のログ出力するんかい！
あと詳細ログ出せないっていうけど、
各メソッドで出すことでどれだけ詳細度があげられるんだ？
全メソッドでそれはありえんだろ。
858:デフォルトの名無しさん
06/10/18 16:39:00
>>857
どのイベントから呼び出したどのメソッドの中にあるメソッドの…
と、経路と部位の特定が簡単になるのが、ダメなのか？
ユーザーが言うバグにも早く対応ができるし。
つーか、何に対してそこまでの否定を？
859:デフォルトの名無しさん
06/10/18 16:39:16
すいません、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
みたいなことができるといいのですが。
要はコントロール名からオブジェクトを取得できればいいわけなんですけれど。
860:デフォルトの名無しさん
06/10/18 17:19:22
>>859
Controlsプロパティでググれ
861:デフォルトの名無しさん
06/10/18 17:25:02
>>858
StackTraceとか。
そもそもその例外を外に出すのか、内部で処理するのか、どちらが正しいってのはその関数の責務の問題になるし。
862:デフォルトの名無しさん
06/10/18 17:57:38
>>861
StackTraceって>>858みたいな使い方できたっけだぜ？
あと、例外の処理は関数の責務というより、
プロジェクト全体、退いては会社などのポリシーによって統一されなければいけないもんだぜ。
派遣がたまに来て、ルールぶち壊す奴がいるが、
そういうのが一番アスホールになるんだべ？
863:デフォルトの名無しさん
06/10/18 18:12:51
スタックトレースでほぼ見えるだろ。
全メソッドでそういうことするのはおかしいて言ってる。
.NETでの例外処理において、やってはいけないこと、に挙げられてるよ。
864:デフォルトの名無しさん
06/10/18 18:14:35
>>863
誰が言ってるの？
何をやってはいけないの？
865:デフォルトの名無しさん
06/10/18 18:17:33
全メソッドでException型でキャッチして再スローするようなこと。
866:デフォルトの名無しさん
06/10/18 18:20:44
>>865
まあ、まずはソースだ。
MSが言ってるレベルだと信頼は無いからな。
大体、本当にやってはいけないことなら、コーディングレベルでエラーが出るだろ。
867:デフォルトの名無しさん
06/10/18 18:23:09
ソース出せ
ああ、ベンダのいうことは信用できないから駄目だよ
868:デフォルトの名無しさん
06/10/18 18:24:05
だったら.NETなんかつかわなけりゃいい
869:デフォルトの名無しさん
06/10/18 18:26:53
例外のスローや再スローが非常に高コストなのは
常識だと思ってた。
ていうか、全メソッドでやるなら例外なんて仕組みいらんだろ。
870:デフォルトの名無しさん
06/10/18 18:27:56
EUCコードのデータを取り込んで表示させるにはどうすればよろしいのでしょうか？
そのままだと文字化けしてしまうのでSJISやUTFに変換しないと駄目でしょうか？
871:デフォルトの名無しさん
06/10/18 18:30:48
ゲームでも作ってるんじゃないからコストなんか考えない。
バグが出ない、修正やカスタマイズがし易い、何か起こったとき直ぐに場所と原因が突きとめられる。
VB.NETで重要なのはこの3点だけ。
メモリが足りないのなら、メモリを積め。
遅いのなら、速いマシンを買え。
コストをシビアに考えるなら、VBなんか使わねーよ
872:デフォルトの名無しさん
06/10/18 18:30:58
独立したスレッド等、処理を断続させる場合だけ、TryCatch
それ以外は、イベントハンドルとして処理。
これでいいだろ。
全メソッドでTryCatchなんてありえん。
初心者と技術のない職場のポリシーだけだ。
873:デフォルトの名無しさん
06/10/18 18:32:33
>>871
それは単なるお前の自論だろ。
874:デフォルトの名無しさん
06/10/18 18:34:56
>>873
IBMで教わった持論なんだがな。
875:デフォルトの名無しさん
06/10/18 18:36:02
>>872
VB6のときは、イベント内のみにしかイベントハンドルを書かなかった口か？
876:デフォルトの名無しさん
06/10/18 18:38:51
>>871
try～catch～finally～内にバグがないとも限らない。
一元管理されるほうが、どう考えても効率いいし、バグが入りにくい。
877:デフォルトの名無しさん
06/10/18 18:40:02
>>875
どう解釈しても意味不明だわな
878:デフォルトの名無しさん
06/10/18 18:44:20
グダグダだな
879:デフォルトの名無しさん
06/10/18 18:46:36
>>876
それはリスクポリシーの取り方だろ。
可読性の良いコードなら、catchやfinallyにバグが入り込む可能性は低い。
try内の問題が直ぐ判別できるから尚良い。
つーか、1メソッド、try～catch～finally～含めても、
コードなんて20行も無いだろ？
catch内でも2～3行なもんだろ？
880:デフォルトの名無しさん
06/10/18 18:47:08
>>870
ここ読んでみたら？
URLﾘﾝｸ(dobon.net)
881:デフォルトの名無しさん
06/10/18 18:59:37
お前有り得ない例外処理が反乱してるのを見たことないのか？
882:デフォルトの名無しさん
06/10/18 19:02:07
>>881
無いね。
危ない例外は完全に殺してしまうし、
例外処理用にかなりこなれた関数も用意してるし。
883:デフォルトの名無しさん
06/10/18 19:10:21
>>879
>コードなんて20行も無いだろ？
そうとは限らないだろ・・・どんだけ規模の小さいプログラムよ
884:デフォルトの名無しさん
06/10/18 19:11:34
>>882
例外処理用に関数用意するなら、
最初から、ThreadExceptionイベントをハンドルして処理するだけでいいだろが
885:デフォルトの名無しさん
06/10/18 19:11:57
>>883
1メソッド20行にも納められないのかよ。
どんだけ、汚いプログラムだよｗ
886:デフォルトの名無しさん
06/10/18 19:13:34
>>884
趣旨が間違えているぞ。
運用に入ってからでも、ユーザーに気付かれず、
簡単に且つ素早く、エラーを起こしている箇所を特定しなければならないんだよ。
887:デフォルトの名無しさん
06/10/18 19:21:09
>>879
>可読性の良いコードなら、catchやfinallyにバグが入り込む可能性は低い。
可読性は関係ないだろー
そこにバグがあると動作中のバグがどこにあるのかわからないことだってある。
888:デフォルトの名無しさん
06/10/18 19:25:03
>>886
ThreadExceptionイベントで、
簡単に且つ素早く、エラーを起こしている箇所を特定できない状況をおしえてくれよ。
そもそもユーザーに気づかれない機能って何だよ。
889:デフォルトの名無しさん
06/10/18 19:26:55
つか、スタックトレースを知らないってオチはないよな…
890:デフォルトの名無しさん
06/10/18 19:29:05
.NET the final frontier.
891:デフォルトの名無しさん
06/10/18 19:31:54
ThreadExceptionイベントで取れるわけだが・・・
892:デフォルトの名無しさん
06/10/18 19:38:11
スタックトレースは厳密な経路ではない
893:デフォルトの名無しさん
06/10/18 19:42:18
結局スタックとレース以外でcatchやfinallyは必要ないってオチですか？
894:デフォルトの名無しさん
06/10/18 19:45:00
厳密な経路ってどんなん？
スタックトレースでは困るほど異なるもんなのか？
895:デフォルトの名無しさん
06/10/18 19:46:30
そんなに場所特定したいならpbd付けとけ
896:デフォルトの名無しさん
06/10/18 19:47:08
pdbだorz
897:デフォルトの名無しさん
06/10/18 19:47:53
全メソッドでExceptionをキャッチ
経路の詳細情報をログ出力
そして再スローって
具体的にどんなコードになるんだ？
898:デフォルトの名無しさん
06/10/18 19:48:36
スタックトレースってReleaseとDebugで挙動が異なるんじゃなかった？
899:デフォルトの名無しさん
06/10/18 19:50:41
ソースのパスと行番号が出るだけ
900:デフォルトの名無しさん
06/10/18 19:50:49
>>897
あまりいじりたくないコードになりそうだなｗ
901:デフォルトの名無しさん
06/10/18 19:51:24
どこで例外が起きてるかそこまでして知らなくてはならないということは、
どうしようもないパゲッティで、どっちらけなコードではないか?
902:デフォルトの名無しさん
06/10/18 19:56:15
>>901
お前らのコードよりも見やすい自信はある。
但し、サブルーチンが多いので、奥まで入れてグチュグチュする必要はある。
903:デフォルトの名無しさん
06/10/18 19:59:15
スパゲッティじゃんw
904:デフォルトの名無しさん
06/10/18 20:13:17
>>903
なんだ？
お前はサブルーチンのないコードが正当だというのか？
普通、コメントや改行、宣言を除いて、メソッドで処理に書ける行は5～10行だぞ。
それ以上長くなると、可読性のないコードになる。
それだと、一つ一つサブルーチンにしてしまった方が良い。
905:デフォルトの名無しさん
06/10/18 20:16:00
厳密もなにも、メソッド内で得れる経路情報なんて、
ThreadExceptionイベントでも取得できますよ。
それにさ、メソッドごとに特化した例外処理なんて入れてたら、
それこそ、そこにまでバグが潜む可能性があるんだからさ、
決まり文句かくならThreadExceptionイベントで十分だろ。
906:デフォルトの名無しさん
06/10/18 20:18:54
>>904
つまり、10000ステップのソースなら、
1000～2000メソッドあるってことですね。
907:デフォルトの名無しさん
06/10/18 20:20:29
>>906
つ共通化
908:デフォルトの名無しさん
06/10/18 20:20:59
>>905
メソッド内の例外処理は全て同じ。
909:デフォルトの名無しさん
06/10/18 20:22:52
行数が少ないほど可読性が高いと思ってるのか？
DBの正規化でも、同じことが言えるだろ？
簡単な電卓プログラムじゃないんだから。
910:デフォルトの名無しさん
06/10/18 20:25:12
>>907
お前のステップ換算は共通化する前のソースなのか？
>>908
全て同じなのに、ThreadExceptionイベントでダメな理由は何？
911:デフォルトの名無しさん
06/10/18 20:26:39
ま、どうでもいいけど、
たった１０００ステップに１００も２００もメソッド作らんね。
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
コテハンつけるかもしくはアンカー打ってくれ。
何がなんだかさっぱりわからんｗ
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
構造化例外処理といいながら、全メソッドに関数呼ぶ同じ１行ですか？ﾜﾗｶｼﾃｸﾚﾙｾﾞ
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
せめて１人くらいには通じる話をしてくださいです～
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
＼ ￤ /
＼ ￤ /
／￣￣ ヽ,
/ ', / ＿/＼／＼/＼／|＿
＼ ﾉ//, {0} /¨`ヽ {0} ,ﾐヽ / ＼ ／
＼ ／ く ｌ ヽ._.ノ ', ゝ ＼ ＜ バーカ ＞
／ ／⌒ ﾘ ｀ー'′ ' ⌒＼ ＼ ／ ＼
( ￣￣⌒ ⌒￣ ＿) ￣|／＼/＼/＼/￣
｀￣￣｀ヽ /´￣
| |
－－－ ‐ ﾉ ｜
／ ﾉ －－－－
/ ∠＿
－－ | 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
俺の職場のルールが正しければ、お前らが何て言おうと関係ない。
俺の会社はお前らみたいな零細とは違うんだからなｑｑ
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
盛り上がったなｗｗｗ
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:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。