トップページ⇒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/
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は、どういう場合に使われますか？
0709デフォルトの名無しさん2007/12/12(水) 08:14:59
すり抜けも何も、ハンドルしてない〜Exceptionが発生したら.、NET側でダイアログ出して勝手に止めるだろ。
0710デフォルトの名無しさん2007/12/12(水) 08:27:21
>>693
そういうのはヒトに向かって書いている場合もあるんでしょ。
「俺様はちゃんとここで例外が起こりうることを認識してコードかいてるよ」
って明示するために。

必ずしも処理上必要だから書いてるわけじゃないんだよ。
あ、いつも常にそうだとは言ってないから勘違いしないでね。
0711デフォルトの名無しさん2007/12/12(水) 09:01:46
>>710
キャッチって多段で追跡できちゃったりするの？
できないならダメだろ。
0712デフォルトの名無しさん2007/12/12(水) 12:20:04
>>711
できるじゃん
0713デフォルトの名無しさん2007/12/12(水) 12:23:19
独自の例外定義はＭａｉｎでキャッチ、それをスローする例外は
イベントに追加してキャッチさせるのが常識。
0714デフォルトの名無しさん2007/12/12(水) 12:32:17
ここは「よくわからない日本語のサンプル」を投稿するスレじゃないよ
0715デフォルトの名無しさん2007/12/12(水) 13:45:33
開発中はキャッチするなといっていた者だが
開発完了したら、一番上でキャッチしてメッセージを出して終了するようにする
まあ使われないのが理想だが
0716デフォルトの名無しさん2007/12/12(水) 14:43:31
>>710
問題は、デバッガがthrow;でブレークして、
例外が投げられた瞬間のブレークが失われることだ
例外が投げられた瞬間のブレークがあれば何が間違っていたか大抵全部分かる
それを捨てる理由になると思うか？
0717デフォルトの名無しさん2007/12/12(水) 15:29:09
何行目で初回例外が発生したか調べてそこに赤丸付ければいいだろ。
0718デフォルトの名無しさん2007/12/12(水) 15:34:07
>>717
その作業は無駄だし
例外が起きなくてもその行で毎回止まるぞ
0719デフォルトの名無しさん2007/12/12(水) 15:38:47
BitmapImage image1 = new BitmapImage();
BitmapImage image2 = new BitmapImage();
...
...
...
.

って一つずつ書くのが面倒なんですが、まとめて書ける方法ってありますか？
0720デフォルトの名無しさん2007/12/12(水) 15:44:55
>>719
配列にしてループ
0721デフォルトの名無しさん2007/12/12(水) 15:57:55
結局したほうがいいの？しないほうがいいの？
0722デフォルトの名無しさん2007/12/12(水) 16:02:12
>>721
自分で考えられないやつは2chなんか使うな
0723デフォルトの名無しさん2007/12/12(水) 16:07:15
>>722
>>1
0724デフォルトの名無しさん2007/12/12(水) 16:49:02
catch{}のなかで正常に戻せた場合にそのまま進むにはどうすればいいの?
0725デフォルトの名無しさん2007/12/12(水) 16:52:14
そのまま進むとは？
0726デフォルトの名無しさん2007/12/12(水) 16:53:46
通常進行で
0727デフォルトの名無しさん2007/12/12(水) 16:57:08
そのまま進め
0728デフォルトの名無しさん2007/12/12(水) 16:57:48
例外を投げたメソッドの実行を続けるということ?
続行できないから例外投げてるのに戻してどうすんの
だいたいなんで正常に戻せたってわかるの? クラスやメソッドの実装によるだろそんなの
0729デフォルトの名無しさん2007/12/12(水) 17:10:27
catchの中で正常に戻せる意味が分からない
それはもともと例外を投げるべきではなかったんじゃないか
0730デフォルトの名無しさん2007/12/12(水) 17:11:56
っ ソフトを再起動してもらう
0731デフォルトの名無しさん2007/12/12(水) 17:13:36
復活の呪文
0732デフォルトの名無しさん2007/12/12(水) 17:17:03
ぴぴる ぴる ぴ(ry
0733デフォルトの名無しさん2007/12/12(水) 17:20:30
try
{
　ケーブルが抜けていたとか
　ディスクの入れ忘れとか
　電源入れ忘れとか
}
catch
{
　えらー表示した
　対処された
}

そんな感じの場合なんだけど
0734デフォルトの名無しさん2007/12/12(水) 17:23:52
じゃあそのまま進めばいいだろ
とりあえずキャッチしておけば実行停止することはないんだからあとは君の判断で
0735デフォルトの名無しさん2007/12/12(水) 17:28:04
while (true) {
 try {
  例外の起きる処理;
  break; // 完了
 } catch ( .. ) {
  if ( ! Retry ) break;
 }
}
0736デフォルトの名無しさん2007/12/12(水) 17:31:45
例外は有害だから使うべきではない。
0737デフォルトの名無しさん2007/12/12(水) 17:32:53
while(true)
{
　try
　{
　やってみる();
　　break;
　}
　catch(デバイス見つからないException)
　{
　　if(ShowDialog("デバイス見つからないよ") == Result.Cancel))
　　　throw new CancelException("実行はキャンセルされました");
　}
　catch(ディスク入ってないException)
　{
　　if(ShowDialog("ディスク入ってないよ") == Result.Candel))
　　　throw new CancelException("実行はキャンセルされました");
　}
}
0738デフォルトの名無しさん2007/12/12(水) 17:34:10
try
{
　ケーブルが抜けていたとか
　ディスクの入れ忘れとか
　電源入れ忘れとか
}
catch
{
　ケーブルを挿すとか
　ディスクを入れるとか
　電源を入れるとか
}
0739デフォルトの名無しさん2007/12/12(水) 17:46:25
リトライとかはcatch内じゃなくてもっと上の仕事じゃないか？
0740デフォルトの名無しさん2007/12/12(水) 17:58:22
その場で出来るものはその場でやらないとわけわからなくなると思うが
■ このスレッドは過去ログ倉庫に格納されています