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

ふらっとC#,C♯,C＃（初心者用） Part21

■ このスレッドは過去ログ倉庫に格納されています
0001ななしぃ#2007/11/18(日) 15:53:41
このスレッドは
「どんなにくだらないC#プログラミングに関する発言でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問など、
勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。

前スレ: ふらっとC♯, C＃（初心者用） Part20
http://pc11.2ch.net/test/read.cgi/tech/1191036844/
0609デフォルトの名無しさん2007/12/11(火) 11:43:08
結局Win32のカオス具合をなぞってるだけだな
0610デフォルトの名無しさん2007/12/11(火) 11:51:29
>>608
それはキャストじゃなくて型変換（Convert）だろ。
TypeConverter/TypeDescriptor でも使えば？
0611デフォルトの名無しさん2007/12/11(火) 12:25:54
>>606
TryParseは2.0になって利便性のために新たに付け加えられたのであって、
決して「誤り」ではないよ。
0612デフォルトの名無しさん2007/12/11(火) 12:28:32
outで返すとC#でしか使えないことないか？

パラノイア的に統一性に拘らないのであれば（というのは、これに病的に固執する奴っているからね）
値を返さないメソッドに関してだけ例外を返すようにする（返値が必要なのは普通に例外投げる）
というやり方の方が俺は好きだな。
06136112007/12/11(火) 12:28:47
>>606
TryXの使い方のガイドラインあるから読んどけ
http://msdn2.microsoft.com/ja-jp/library/ms229009(VS.80).aspx
0614デフォルトの名無しさん2007/12/11(火) 13:29:25
>>612
outが嫌なら戻り値用の構造体を作ったっていい
>>613
パフォーマンス上の理由なんてのは的外れだ
その例外がめったに起こらなければ起こらないほど
例外のキャッチし忘れは深刻なバグになる
起こるか起こらないか分からないようなエラーが起こるものが
通常のメソッドと見た目全く同じに用意されていて
エラーにそなえてtryで囲めというのは間違い探しをしろといっているようなものだ
単に無駄だ
バグであることが分かりやすくなるように設計するべきだ
0615デフォルトの名無しさん2007/12/11(火) 13:30:22
平日の昼間っから暇なんだなあ
0616デフォルトの名無しさん2007/12/11(火) 13:41:10
なんでここは3行にまとめられない奴ばっかりなんだろ
0617デフォルトの名無しさん2007/12/11(火) 13:57:19
例外のキャッチし忘れはむしろ深刻にはならない。
0618デフォルトの名無しさん2007/12/11(火) 14:09:17
めったにないことだけどある環境では100回に1回ぐらい例外が投げられることがある
catchしてないのにテストをすり抜けてパッケージソフトとして出荷されてしまった
どうなる？
0619デフォルトの名無しさん2007/12/11(火) 14:14:53
例外は絶対投げちゃダメ！とかTryParseは誤り！とか言う事が極端だな
共有すべき普遍的な知識と自分だけの信念は区別しないと
0620デフォルトの名無しさん2007/12/11(火) 14:16:17
そんな事言ってる人居たっけ
0621デフォルトの名無しさん2007/12/11(火) 14:18:28
>>619
TryParseは正しい
正しく呼び出してもエラーが起こりうる場合例外は投げるべきじゃない
とは言った
0622デフォルトの名無しさん2007/12/11(火) 14:27:16
ちなみにTry〜を使うべきだと俺が考えるものには
メソッドが成功するかどうかが自分のプログラムの状態以外の要因で決まるもの(ハードディスクとかNetworkとか)と
それが正しい呼び出しであるかをテストする機能も正しい使い方のうちに含むもの(TryParse)と二通りある
0623デフォルトの名無しさん2007/12/11(火) 14:33:13
ここふらっとスレなんだけど。
0624デフォルトの名無しさん2007/12/11(火) 14:51:59
だからだろ
0625デフォルトの名無しさん2007/12/11(火) 15:12:12
>>618
キャッチし忘れのバグの方がキャッチもしくは例外をかわした場合のバグより
深刻にはならないって言ってるだけだよ。
0626デフォルトの名無しさん2007/12/11(火) 15:17:39
ある環境では100回に一回発生する例外を
常にちゃんと認識しててきっちり対処出来るんなら別だけどな。

あくまでバグがあった場合の話で、
バグがないならその方がいいに決まってる。
0627デフォルトの名無しさん2007/12/11(火) 15:29:08
>>626
しかしある種の例外は確率は低いけど不可避なわけだ
>>622の前者のようなのはそうだ

>>625
間違ってるのにエラーを返さない、例外を投げない
それはただのバグだが防ぐのは難しい
しかし例外のキャッチし忘れは簡単に防げる
防げるものは防いだほうがいいし、それが深刻になる場合だってある
0628デフォルトの名無しさん2007/12/11(火) 16:37:32
http://ufcpp.net/study/csharp/oo_exception.html

例外（exception）とは、本来ならばプログラム中で起こってはいけないことが起こってしまうことをいいます。
堅牢なプログラムを作成するためには、例外が起こったときでもプログラムが異常な動作をしないよう、
しっかりと例外処理（exception handling）を行う必要があります。

0629デフォルトの名無しさん2007/12/11(火) 16:44:57
ここが隔離スレになってるから有効に使ってくれ。
C♯, C＃相談室 Part34
http://pc11.2ch.net/test/read.cgi/tech/1162467959/l50
0630デフォルトの名無しさん2007/12/11(火) 17:04:09
今時戻り値だの構造体だのでエラー情報ずらずら返されたら
どうしようかと思うよ。
0631デフォルトの名無しさん2007/12/11(火) 17:18:14
じゃあメソッドの頭にTryとつけるだけでもいい
エラーが不可避ならばそれを分かりやすく示すべきだ
tryで囲んでないのが一目でバグと分かるように
0632デフォルトの名無しさん2007/12/11(火) 17:25:00
しかし例外の型は何が飛んでくるかわからないからな
バージョンアップで新しい例外が投げられるようになってキャッチできない可能性もあるし
outなり構造体なりで返ってくれば不可避な例外の基本クラスは分かるから
それを投げれば、バグによる例外を含まずにキャッチできる
とにかくcatch{}やcatch(Exception)だけはやってはいけないんだ
0633デフォルトの名無しさん2007/12/11(火) 17:47:00
catch(Exception ex) { ログ保存(ex); throw ex; } は時々やる。
0634デフォルトの名無しさん2007/12/11(火) 17:48:33
だからね、例外が深刻な状況につながることはあまりなくて、
むしろキャッチした上でのバグが深刻な状況につながるんだといってる
0635デフォルトの名無しさん2007/12/11(火) 17:53:23
深刻って何だろう
0636デフォルトの名無しさん2007/12/11(火) 17:58:59
>>633
それやるとデバッガが例外が起きた瞬間でブレイクしてくれないだろ
例外のメッセージの何十倍もその瞬間のブレイクの方が有用だし
0637デフォルトの名無しさん2007/12/11(火) 18:20:55
ケースバイケース
0638デフォルトの名無しさん2007/12/11(火) 18:43:20
>>634
何が言いたいのかよく分からん
それでどうするべきだと言ってるんだ？
0639デフォルトの名無しさん2007/12/11(火) 18:43:43
デバッガの使い方をまず身につけろよ。
最終的にはまず大抵どっかでキャッチするんだから
キャッチしたらアウトなんてのは使い物なならんだろ。

ただ、あえてやってるんじゃないなら
throw e;
はやめとけ。
throw;
でいい。
0640デフォルトの名無しさん2007/12/11(火) 18:45:34
とにかくキャッチすべき、キャッチしないバグは深刻
っていってるみたいだから、
キャッチするバグの方が大抵深刻だよっていってるだけ。
0641デフォルトの名無しさん2007/12/11(火) 18:47:10
ああちょっとちがうか…
キャッチしないバグは、深刻度は比較的低いってこと。
0642デフォルトの名無しさん2007/12/11(火) 18:48:48
何が起きてるか分からない、例外が飛んでこないバグに比べたらね。
0643デフォルトの名無しさん2007/12/11(火) 18:51:03
誰か例外関係のガイドライン書いてちょうだい
0644デフォルトの名無しさん2007/12/11(火) 18:55:18
>>639
大抵どっかでキャッチする時点でデバッガの使い方を間違えている
少なくとも開発中はバグによる例外はキャッチすべきではない
ブレイクすべきだ
キャッチするのはバグを握りつぶす効果しかない

バグでない不可避な例外の場合はキャッチして処理しなきゃならない
その場合でも不可避な例外の基本クラスを設けるとか、必要な処理はやらなきゃならない
漫然と例外を使うとひどいことになる
特にどっかでキャッチされるなんてのは最低の使い方だ

>>640
全然違う
俺はキャッチすべきでないといってる
確率的に低い不可避の例外をキャッチしないことは深刻なバグに繋がる
なら最初からboolを返すなりメソッドシグネチャに書いておくべきだ
0645デフォルトの名無しさん2007/12/11(火) 19:09:38
正直、言ってる事よくわかりませんけど。。。
0646デフォルトの名無しさん2007/12/11(火) 19:13:08
>>596をまず読んでくれ
いろいろ誤解されてるような気がするが
俺はこれを繰り返し言っているだけだ
0647デフォルトの名無しさん2007/12/11(火) 19:21:36
いややっぱりよう分からんぞw

前半は当たり前杉。
後半は何言ってるか意味不明。
特に、
＞どちらにもいえることだが、例外はキャッチするものでは無い
なんだよこれw
0648デフォルトの名無しさん2007/12/11(火) 19:27:49
お前の例外をキャッチして腹ン中がパンパンだぜ
0649デフォルトの名無しさん2007/12/11(火) 19:32:46
>>647
どれが分からないんだ？

正しく呼び出したとしても例外を投げることが不可避であり、必ず対応しなければ破綻する
メソッドが、通常のメソッドと見た目が何も変わらなければ、キャッチし忘れることがありうる
一つ一つのメソッドについて例外が不可避かどうか調べるのは時間の無駄なので、
そういうメソッドは見た瞬間にそれと分かるようにするべきだといっている

具体的にはTry〜にしてboolを返すようにするとか、単に命名規則に含めるとかだ
0650デフォルトの名無しさん2007/12/11(火) 19:37:44
不可避の例外ってのがようわからん。
挙げられてるケースだとただ単にエラーチェックしてないだけだが。
0651デフォルトの名無しさん2007/12/11(火) 19:41:48
不可避の例外については>>622に書いたが何かおかしいか？
0652デフォルトの名無しさん2007/12/11(火) 19:44:52
>>649
あのーお言葉ですけどねえ、
外的な、つまり呼び出し側以外の理由で例外が起こるような処理っていうのはむしろ
文字通り「例外的」なわけで、そういうのは（むろん上手に抽象化ができてさえすれば、
という前提条件つきではあるが・・・）むしろメソッドの意味を見れば
例外が起こりうるかどうかは一目瞭然なんじゃないの？

例えばディスクにアクセスするメソッドならディスクが物理的にお陀仏になったれ例外投げるしかないことは
猿でも分かるでしょw
06536522007/12/11(火) 19:47:00
あ、でもドトネトのファイルストリームはそういう実装になってないんだっけかw
あれって書き込み中のUSBドライブ抜いても何の例外も投げないのなw
0654デフォルトの名無しさん2007/12/11(火) 19:58:48
>>652
そうはいってもプログラムは適当に書かれることがあり
try,catchは往々にして忘れられる

さらにいえば、どのメソッドがどんな例外を投げるかきちんと把握しているのか
どの例外が不可避で、どの例外がバグによるものか
キャッチしていい物としてはならないものはどう見分けるのか
不可避の例外の基本クラスを作り、outでその例外クラスを返すようにすれば
帰ってくる不可避の例外がそのクラスを継承したものであることが保障される

バグであればそれ以外のクラスから派生した例外が飛んでくることになる
バグの例外はキャッチすべきでないから、try,catchで囲む必要すらなくなる
必要とあらばoutで返ってきた例外を飛ばし、基本クラスでcatchすることで
将来返って来る例外が増えたときにも対応できる
06553352007/12/11(火) 20:03:11
try
{
Aaa(p1);
}
catch (HogeException e)
{
Console.WriteLine("{0} HogeException caught.", e);
}
catch
{
throw;
}

こんなふうに投げちゃいかんの？
メソッドやクラス内で処理する分はcatchしてそれ以外は上に投げる
投げ先が制御できないなら共通エラー処理クラス使えばいいと思うんだけど

初めて１週間なんでハズしてたら教えて欲しいです
0656デフォルトの名無しさん2007/12/11(火) 20:03:54
そろそろ隔離スレへいってくんない
0657デフォルトの名無しさん2007/12/11(火) 20:06:54
>>655
デバッガはthrow;のところで止まって例外が投げられた瞬間の情報が失われるけど
それでいいなら
それを避けたければデバッグ→例外を選んで投げた瞬間にブレイクしてほしい
例外にチェックをつけてもいい
0658デフォルトの名無しさん2007/12/11(火) 20:13:01
つまりSystem.IO下の関数には全てTryを付けた方が良いということだな。
0659デフォルトの名無しさん2007/12/11(火) 20:14:46
そうだ全部にHRESULTを返すようにしようぜ
0660デフォルトの名無しさん2007/12/11(火) 20:15:15
もう全部Debug.Failで
0661デフォルトの名無しさん2007/12/11(火) 20:18:49
S_OK
0662デフォルトの名無しさん2007/12/11(火) 20:38:38
>>658
確かにHDが一杯とかになったら何か処理はしなきゃならないから
ほとんどにTryがいるかもな
Tryってついてないから忘れがちだが
0663デフォルトの名無しさん2007/12/11(火) 21:00:28
ま〜趣味の人は何でもいいんでないの
俺なんかの扱ってる仕事は止まるとニュースになるようなのばっかりだが
0664デフォルトの名無しさん2007/12/11(火) 21:06:27
なんというマイクロソフト信者
そんなミッションクリティカルな用途にC#使うなんて、
普通の人間には命がいくつあっても出来ない。
0665デフォルトの名無しさん2007/12/11(火) 21:09:45
>>663
某首相の中の人とかか?
0666デフォルトの名無しさん2007/12/11(火) 21:17:06
>>656
諦めな
もし隔離スレを埋めたいのであればそっちにネタ投下すればいい
0667デフォルトの名無しさん2007/12/11(火) 21:27:39
>>663
どうせCOBOLでやるような糞仕事をリプレースしただけだろ
0668デフォルトの名無しさん2007/12/11(火) 21:32:32
規模の大きいところほど、技術的には保守的だったりだすからね。
0669デフォルトの名無しさん2007/12/11(火) 23:01:19
捨て台詞を吐いて背を向けた犬をいつまでもいたぶるな。
0670デフォルトの名無しさん2007/12/11(火) 23:05:00
C#で学んだことって他の.NET言語でも役に立ちますか？
0671デフォルトの名無しさん2007/12/11(火) 23:06:51
はい
0672デフォルトの名無しさん2007/12/11(火) 23:07:02
たつ
0673デフォルトの名無しさん2007/12/11(火) 23:08:38
わかりました。
0674デフォルトの名無しさん2007/12/11(火) 23:17:11
C#できればVB.NETは一日触れば使える
0675デフォルトの名無しさん2007/12/12(水) 00:00:35
必要だから例外なんて物ができたんじゃないのか？
それを使うなって┐(´д｀)┌
0676デフォルトの名無しさん2007/12/12(水) 00:10:23
>>675
バグを通知するためにはものすごく必要だ
エラーで分岐するにはそのままでは不適切な仕組みだ
適切に使わないといけない
0677デフォルトの名無しさん2007/12/12(水) 00:18:47
リストビューのColumnWidthChangingイベントが拾えません！！
0678デフォルトの名無しさん2007/12/12(水) 00:27:11
VC#2008betaでアプリを作るとき、WindowsフォームアプリとWPFアプリが選択できるけど、
今から始めるなら当然WPFアプリが良いんだよね？
0679デフォルトの名無しさん2007/12/12(水) 00:36:02
ご自由に
0680デフォルトの名無しさん2007/12/12(水) 00:36:29
例外ってのはコンピュータの内部ではどんな状態になってるの？
0681デフォルトの名無しさん2007/12/12(水) 00:49:00
他の場所でチェック済みのオブジェクトを渡したりする以外では必ずtry-catch使ってる。
例外で処理分岐する場合もあれば、戻り値でも処理分岐する場合あるし臨機応変
0682デフォルトの名無しさん2007/12/12(水) 00:51:15
>>680
例外ハンドラが見つかるまで積まれたスタックフレームをすっとばす。
0683デフォルトの名無しさん2007/12/12(水) 00:53:32
皆細かくやってんだね。
俺なんか自分で作ったクラスは
try catchでcatchしたらthrowだよ。
でaspx.csで例外を受け取ったらRedirectでエラーページに遷移させる。
社内システムなんでそんなもんだぜ。
0684デフォルトの名無しさん2007/12/12(水) 00:54:46
>>681
それは臨機応変じゃなくて規約がなくその都度注意力をもって判断せねばならず
バグかどうかがドキュメントを参照しないと分からないということだろう
最悪の方法だ
0685デフォルトの名無しさん2007/12/12(水) 00:58:45
開発完了したシステムなら例外を一番上で全キャッチして
必要なエラーメッセージを出すようにすればいいさ
しかし開発中はバグの例外はキャッチしちゃいかんのだ
0686デフォルトの名無しさん2007/12/12(水) 01:03:09
>>674
VB.NET使う必要も技術的利益も無いんだがな・・・
なんでVB.NET選ぶかね・・・
0687デフォルトの名無しさん2007/12/12(水) 01:08:47
デバッガ慣れすると必要なログすら入れない奴が出てくる。
エラーメッセージ無視して「デバッガで追おうとしたけど再現しません」とかいう奴すら・・・
0688デフォルトの名無しさん2007/12/12(水) 01:12:31
なんせ例外が起こった瞬間のブレイクほど便利なものはないからな
エラーメッセージなんて例外で適切にブレイクできてりゃ最小限でいいんだ
0689デフォルトの名無しさん2007/12/12(水) 01:17:09
開発中にcatch無しってのは当たり前の話で、
エラーかどうかは殆どの場合ドキュメント見るんじゃないの？
0690デフォルトの名無しさん2007/12/12(水) 01:19:15
出来ることは違いないので、VB使うってのはその人の選択肢だね。文法の慣れとか。
0691デフォルトの名無しさん2007/12/12(水) 01:22:52
呼び出し側のミスでない例外ならばこの基本クラスを継承した例外を投げます
と決めておけば、それをキャッチしておけばいい
例外がキャッチできずすり抜けていったら呼び出し側のミスだ
向こう側が間違ってるのかもしれないがその時はドキュメントをよく読んで質問するしかない
0692デフォルトの名無しさん2007/12/12(水) 01:26:13
割り込みますがループ中の処理などの場合はどうなるのですか
例外だと中断されるのですよね？こんな場合は戻り血とかで判断するのですか
0693デフォルトの名無しさん2007/12/12(水) 01:36:59
>>655
そういえば正しい方法を言ってなかった気がする

catch
{
throw;
}

これはいらないからなくすべき
例外が投げられた瞬間の情報が失われるから
0694デフォルトの名無しさん2007/12/12(水) 01:41:37
例外って「これ以上処理を続けられるとマズイ」っていうときに投げるもんじゃないの?
0695デフォルトの名無しさん2007/12/12(水) 01:42:53
>>694
そりゃそうだ
0696デフォルトの名無しさん2007/12/12(水) 01:42:55
みんなこれくらいは読んでる？
http://msdn2.microsoft.com/ja-jp/library/ms229014.aspx
0697デフォルトの名無しさん2007/12/12(水) 01:45:45
俺も読んでくる
0698デフォルトの名無しさん2007/12/12(水) 01:49:34
もうオイラはスローして寝ます
0699デフォルトの名無しさん2007/12/12(水) 01:51:23
throw spoon;
0700デフォルトの名無しさん2007/12/12(水) 01:59:48
投げたらアカン
0701デフォルトの名無しさん2007/12/12(水) 02:02:26
＞他の場所でチェック済みのオブジェクトを渡したりする以外では必ずtry-catch使ってる。
必ずってどのレベルで必ずなの？
メソッド呼び出し全部？
catchしてその場でどうにかできるのなんて一部な気がするんだが。
まあラップして投げなおしはあるかもしれんが。
そうでなくみんな戻り値とかでエラー返して上位に通知してるなら
それこそ単純に例外ですむ話し出しってか上位への通知を細かに書かなくてすむ
ってのが例外のメリットのひとつだと思うんだが、
多分そういうことではないんだよね？
0702デフォルトの名無しさん2007/12/12(水) 02:04:13
業務アプリなんかだと、業務実装者にはほとんど例外処理なんて書かせないしな。
その場で処理してしまうような例外は別だけど。
0703デフォルトの名無しさん2007/12/12(水) 02:09:29
＞非常に一般的なエラーの場合には null を返します。
＞たとえば、ファイルが見つからない場合には File.Open は null を返しますが、
＞ファイルがロックされている場合には例外を返します。
http://msdn2.microsoft.com/ja-jp/library/seyhszts.aspx

このガイドラインはうんこそのものだな
怪しそうな全ての場合においてnullを返すかどうかを一々調べろといってるのか？
0704デフォルトの名無しさん2007/12/12(水) 03:59:25
業務アプリやパッケージで実行時エラーが出るのはやばいよな？
なのでcatchしてログ＆メッセージ出して問い合わせ促してるけど
catchしないって人はリリース後に実行時エラー発生したらどうやって対応すんの？
0705デフォルトの名無しさん2007/12/12(水) 04:04:49
データの喪失も破壊も甘んじて受け入れる
0706デフォルトの名無しさん2007/12/12(水) 04:10:42
アプリケーションの一番高いレベル、つまりMainに近いあたりでキャッチして
ログやメッセージ出してアプリを中断が常套。MSのガイドラインでもこうなってるな。
0707デフォルトの名無しさん2007/12/12(水) 04:41:05
.NETのクラスライブラリの出す例外の扱いの話と、
その上に構築するアプリケーションにおける例外のデザインの話は
分けて考えないと論点がはっきりしない気がするな。
0708デフォルトの名無しさん2007/12/12(水) 05:44:24
ProfessionalColors.ImageMarginRevealedGradientBegin
と
ProfessionalColors.ImageMarginGradientBegin
の違いって何ですか？

ImageMarginRevealedGradientBeginは、どういう場合に使われますか？
■ このスレッドは過去ログ倉庫に格納されています