トップページ⇒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/
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
その場で出来るものはその場でやらないとわけわからなくなると思うが
0741デフォルトの名無しさん2007/12/12(水) 18:07:43
>>740
リトライが必要な処理群としてまとめておいて呼び出し側で再呼び出しした方がｲｸﾅｲ？
0742デフォルトの名無しさん2007/12/12(水) 18:08:33
>>741
ソースコードで頼む
0743デフォルトの名無しさん2007/12/12(水) 18:10:19
つまりTryGetValueか
0744デフォルトの名無しさん2007/12/12(水) 18:11:34
GetLastError()
有り得ない値返し
エラーコード返し
BOOL返し
HRESULT返し
C++の例外
.netの例外
構造化例外
が入り乱れるVCよりましじゃないか。
0745デフォルトの名無しさん2007/12/12(水) 18:12:00
再利用してソースが分かりやすくなるならいいんだけどな
分岐では分かりにくくなることが往々にしてある
0746デフォルトの名無しさん2007/12/12(水) 18:23:01
t6rs4:s.td@84s4:s.tfvsc;c@;d@'uetu
0747デフォルトの名無しさん2007/12/12(水) 18:40:44
VBのソースで悪いけど。

dim reader as IDbReader = command.ExecReader()
while reader.Read()
  aa = DirectCast(reader("aa"), string)
  bb = DirectCast(reader("bb"), Integer)
  :
  :
End While

DBから読み込むコードで、ISAMライクなウンコなテーブル設計で、whileの中のコードが数十行続いてるとします。
項目はNOT NULL制約が設定されてないから、reader("・・") で DBNull が帰って来ることもあります。

こういうときは、一行ずつifでDBNullか判定しますか?
それとも、try でくくって、一括してcatchしますか?
0748デフォルトの名無しさん2007/12/12(水) 18:57:14
まず
public static T Get<T>(this IDbReader reader, string name)
{
　object item = reader(name);
　if(item == DBNull)
　　throw new DBNullException(name + "がDBNullです");
　return (T)item;
}

こんなんを作って、DBNullExceptionだけキャッチすればいいんじゃねえの
何がしたいのかよくわからんけど
0749デフォルトの名無しさん2007/12/12(水) 19:05:01
>>748
object型をstringやらintegerにキャストするとき、DBNullだったら、例外がでるので、
そういうのはなくても大丈夫です。

if reader("・・") <> DBNull.Value then 
  aa = DirectCast(reader("・・"),・・・)
else
  なんかエラー処理
end if

みたいに一行ずつ判定するか、

try
  aa = DirectCast(reader("・・"),・・・)
  bb = DirectCast(reader("・・"),・・・)
  :
catch ex as キャストの例外
  :
End Try

みたいにまとめてキャッチするかってことです。
0750デフォルトの名無しさん2007/12/12(水) 19:09:11
>>749
InvalidCastExceptionをそのまま捕まえるのはいただけない
catchするのはバグによる例外でないことが明らかなものにするべきだ
エラー処理に何をするのか、DBNullが帰ってくる頻度がどのくらいで
例外がパフォーマンスに影響するのかによって変わってくる
0751デフォルトの名無しさん2007/12/12(水) 19:14:01
>>750
たしかに、NULLが入ってるデータが多いと使い物にならないくらい遅くなりますね。

それでは、基本的にNULLは入ってないデータだけど、NOT NULL制約がないので「NULLもありえる」という
程度で。
例外は>>748みたいなラッパーで、独自のものを投げるという状況で。

ifでチェックしたほうがいいか、まとめて例外で処理したほうがいいか。
0752デフォルトの名無しさん2007/12/12(水) 19:15:17
お前ら例外が好きだな
0753デフォルトの名無しさん2007/12/12(水) 19:35:51
public static bool SetMember(this IDbReader reader, string name, Action<object> setMember)
{
　object item = reader(name);
　if(item == DBNull.Value)
　　return false;
　 setMember(item);
return true;
}

Func<bool>[] setMembers = new Func<bool>[]{
　() => reader.SetMember("aa", obj => aa = (string)obj),
　() => reader.SetMember("bb", obj => bb = (int)obj),
　 ...
};

foreach(var setMember in setMembers)
{
　if(setMember() == false){ エラー処理 }
}

例外がパフォーマンスを脅かすならこうかな
0754デフォルトの名無しさん2007/12/12(水) 19:42:12
横から失礼
例外投げるとパフォーマンスを脅かすってのはなんで？
例外クラスのインスタンスを生成するから？
それとも別のもっと大きな要因があるのかな
0755デフォルトの名無しさん2007/12/12(水) 19:45:32
URIを返す関数で、失敗した場合の理由を
return new Uri("error://imifumei/");
みたいな感じで返すのはありですか？
0756デフォルトの名無しさん2007/12/12(水) 19:46:45
間違った
public static bool SetMember<T>(this IDbReader reader, string name, ref T member)
{
　object item = reader(name);
　if(item == DBNull.Value)
　　return false;
　member = (T)item;
　return true;
}

Func<bool>[] setMembers = new Func<bool>[]{
　() => reader.SetMember("aa", ref aa),
　() => reader.SetMember("bb", ref bb),
　 ...
};

foreach(var setMember in setMembers)
{
　if(setMember() == false){ エラー処理 }
}

こうでした
0757デフォルトの名無しさん2007/12/12(水) 19:59:14
見たか
これがC# 3.0の力だ
早く乗り換えたまえ
0758デフォルトの名無しさん2007/12/12(水) 20:07:01
>>755
なしです
例外またはTry〜を使いなさい
0759デフォルトの名無しさん2007/12/12(水) 20:09:41
>>758
nullを返すのは?
0760デフォルトの名無しさん2007/12/12(水) 20:10:33
>>759
個人的には、名前の末尾にOrNullをつけないとなしと考えている
つければあり
0761デフォルトの名無しさん2007/12/12(水) 20:14:19
やっぱなしですか。
0762デフォルトの名無しさん2007/12/12(水) 20:16:43
100%なしです
0763デフォルトの名無しさん2007/12/12(水) 20:19:56
例外使わないって人はリリース後のバグどうするんだ？
それにテスト後にｍａｉｎにtry〜catch追加したらテストやり直しだろ
異常系のテストエビデンスに再現性無くなるじゃん
個人作成やパッケージ等すべて自分達で責任取れるものならいいけどさ
0764デフォルトの名無しさん2007/12/12(水) 20:21:34
OrNullってどういうこと。
見たことも聞いたこともない命名規則だな。
0765デフォルトの名無しさん2007/12/12(水) 20:22:07
GetValueOrNull
どっちだよｗ
0766デフォルトの名無しさん2007/12/12(水) 20:25:02
nullable
0767デフォルトの名無しさん2007/12/12(水) 20:26:51
ヌーブラ
0768デフォルトの名無しさん2007/12/12(水) 20:27:05
>>763
バグじゃなくて仕様の中に処理するって書いてある例外は開発中ももちろんキャッチする
問題はそれ以外だ
それ以外が飛んできたらバグだ
これは開発完了したときには飛んでくることがないのが理想だけど
そうもいってられないのでcatch(Exception)で捕まえる文を開発完了後に付け加える
で、謝罪文を表示して終了すればいい
これをテストする必要は別にない
0769デフォルトの名無しさん2007/12/12(水) 20:27:43
うわー首が飛ぶよ
0770デフォルトの名無しさん2007/12/12(水) 20:28:52
LINQでは
First
FirstOrDefault

といった感じでデフォルト値が返りうる場合はOrDefaultをつける
OrNullって書いてなきゃ絶対にnulのチェックを忘れるから俺はOrNullと書くべきだと考えている
0771デフォルトの名無しさん2007/12/12(水) 20:30:39
>>768
多分噛み合ってないんだけど
納品先のあるプログラムでテスト後にソース改変は一切NGだろ？

バイナリのタイムスタンプとCRCが一致しないテスト結果でもOKってなら
何も言えないな
0772デフォルトの名無しさん2007/12/12(水) 20:35:00
>>771
じゃあ付け加えなきゃいい
万一の場合に備えて例外のメッセージを丁寧語にすることを心がけなきゃならんが
ちゃんと出来てるならほんとはcatch(Exception)なんていらん
0773デフォルトの名無しさん2007/12/12(水) 20:41:28







　　　　　　　　　　　　　　　　　　　　　エラーかもね。
　　　　　　　　　　　　　　　　　　　　　たぶんお前らのミスな。

　　　　　　　　　　　　　　　　　　　　　　　　　　[OK]



0774デフォルトの名無しさん2007/12/12(水) 20:42:34
>>772
>ちゃんと出来てるならほんとはcatch(Exception)なんていらん
これはマじゃない予感・・・
0775デフォルトの名無しさん2007/12/12(水) 20:47:31
>>772
また噛み合ってないが、バグ０にはできない。現実的に。
だから「ちゃんとできている」って言うのは実現困難

当然メソッド単位にtry〜catch入れた上での単体テストを通してるし
mainにも付け加えないんじゃ無くて最初から入れてる

たとえプログラムが原因じゃなくてもトラップできる例外はすべて
プログラムの管理しているエラー処理＋ログで処理する
それを元に障害対応しないと対応できない
リリース後に　「プログラムのせいかどうかわからんがエラー終了する」
なんて状況になったら誰が対応するの？
自分達のプログラムが原因じゃない証明をする際にも証拠は必要だし
0776デフォルトの名無しさん2007/12/12(水) 20:49:28
チャンネル争いしてる時にyozuca出てきたけどあんなに可愛いのか
今度イベントあったら絶対見に行くわ
0777デフォルトの名無しさん2007/12/12(水) 20:54:17
>>775
出来ました、テストしてください、という段階でmainにcatch(Exception)を付け加える
それじゃダメなのか？
0778デフォルトの名無しさん2007/12/12(水) 21:16:30
今組んでるの納品したらこれ買うつもりだが。まあ趣味なら何でもいいんじゃないの。
ttp://www.gtnet.co.jp/home/top/usedcar_syosai.asp?NETCODE=7&SHATEN=0510&ZAIKO=1000340500
0779デフォルトの名無しさん2007/12/12(水) 21:18:56
走行距離１００ｋｍか。
普通試乗で自分向きじゃないとか気づくだろ。
0780デフォルトの名無しさん2007/12/12(水) 21:31:08
前から見たらZじゃんw
0781デフォルトの名無しさん2007/12/12(水) 22:26:28
想定される例外は全て処理せよ的な規約を掲げた開発が
うまく行ってるのを見たことがない。
現実の開発要員は思いのほかレベルが低いもんだよ。
保守や改造でもどんどん壊れて行くしね。
十分な費用がかけられる開発ならいいんだけどね〜
0782デフォルトの名無しさん2007/12/12(水) 22:27:31
ちゃんとキャッチする例外としない例外を分けなきゃダメだっての
全て処理せよってのはどういうこっちゃ
0783デフォルトの名無しさん2007/12/12(水) 22:37:07
それをどうやってはっきり定義するの？
0784デフォルトの名無しさん2007/12/12(水) 22:41:21
正しく呼び出さなかったときの例外→キャッチするべきではない
正しく呼び出したとしても起こる例外→キャッチしなければならない
0785デフォルトの名無しさん2007/12/12(水) 22:53:59
↓の文字列が正しいHTTPの応答かチェックして
http://192.168.0.1:2869/gatedesc.xml
の部分だけ抜き出すにはどうすればいいですか？

HTTP/1.1 200 OK\r\n
CACHE-CONTROL: max-age=1800\r\n
DATE: Wed, 12 Dec 2007 13:51:16 GMT\r\n
EXT:\r\n
LOCATION: http://192.168.0.1:2869/gatedesc.xml\r\n
SERVER: Linux/2.4.18_mvl30-ixdp425 UPnP/1.0 Intel UPnP SDK/1.0\r\n
ST: urn:schemas-upnp-org:service:WANIPConnection:1\r\n
USN: uuid:UUID-NTTEW-DUMMY::urn:schemas-upnp-org:service:WANIPConnection:1\r\n
\r\n
0786デフォルトの名無しさん2007/12/12(水) 23:00:23
Regex.Match(hoge, @"http://.*\.xml").ToString();
0787デフォルトの名無しさん2007/12/12(水) 23:01:15
例えば指定されたファイルを読む処理があるとき、
有るはずのファイルが読めなければ
キャッチする必要があるのだろうが、
渡された引数がそもそも間違ってた場合は
キャッチしちゃダメだってことだなｗ
0788デフォルトの名無しさん2007/12/12(水) 23:05:54
ArgumentExceptionとかInvalidOperationExceptionとか
キャスト失敗とか配列の外側を読んだとかぬるぽとか
そういうのは全部キャッチしちゃダメ
0789デフォルトの名無しさん2007/12/12(水) 23:06:43
そうなるとその判断は引数が決まる元になる位置まで
さかのぼらざるを得ないが、そんなのを全体で完全に
矛盾なく出来るとは思えない。
一体誰がそれを決めるの？

せれともそんなのは関係なく、
例えばArgumentExeption系以外はキャッチするとかになるの？
0790デフォルトの名無しさん2007/12/12(水) 23:09:09
引数が悪いのか環境的な本当の例外かなんて
結局分からんてことだろ？
0791デフォルトの名無しさん2007/12/12(水) 23:09:35
メソッドの正しい呼び出し方はメソッド作成者が決める
違反してたら例外が投げられる
それはキャッチしちゃいけない

正しい呼び出しの時に失敗したならばそれとは違う例外が投げられる
それはキャッチしなきゃならん
0792デフォルトの名無しさん2007/12/12(水) 23:11:02
意図的にnull渡したのか、
γ線でメモリが化けたのか分からない。
0793デフォルトの名無しさん2007/12/12(水) 23:12:14
null渡していいとこは引数名にOrNullってつけてくれ
じゃないとわからん
0794デフォルトの名無しさん2007/12/12(水) 23:16:10
キャッチしてどう処理するのかもよく分からない。
結局回復できない場合も多いから、戻り値とかで返さざるを得ないの？
UI層レベルでは想定されるものはキャッチするだろうけど
もっと下層ではいかんともしがたい気がする。
0795デフォルトの名無しさん2007/12/12(水) 23:17:00
コントロールのプロパティってフォームデザイナで編集したり
コード中で直接設定したりする方法があるのですがどういう風に使い分ければいいんですか？
0796デフォルトの名無しさん2007/12/12(水) 23:17:55
それがバグじゃなくて想定内のものなら
キャッチしてエラーメッセージを出して入力待ちに戻れ
■ このスレッドは過去ログ倉庫に格納されています