ふらっとC#,C♯,C＃（初心者用） Part21
■ このスレッドは過去ログ倉庫に格納されています
0001ななしぃ#
2007/11/18(日) 15:53:41「どんなにくだらないC#プログラミングに関する発言でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問など、
勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。
前スレ: ふらっとC♯, C＃（初心者用） Part20
http://pc11.2ch.net/test/read.cgi/tech/1191036844/
0709デフォルトの名無しさん
2007/12/12(水) 08:14:590710デフォルトの名無しさん
2007/12/12(水) 08:27:21そういうのはヒトに向かって書いている場合もあるんでしょ。
「俺様はちゃんとここで例外が起こりうることを認識してコードかいてるよ」
って明示するために。
必ずしも処理上必要だから書いてるわけじゃないんだよ。
あ、いつも常にそうだとは言ってないから勘違いしないでね。
0711デフォルトの名無しさん
2007/12/12(水) 09:01:46キャッチって多段で追跡できちゃったりするの？
できないならダメだろ。
0712デフォルトの名無しさん
2007/12/12(水) 12:20:04できるじゃん
0713デフォルトの名無しさん
2007/12/12(水) 12:23:19イベントに追加してキャッチさせるのが常識。
0714デフォルトの名無しさん
2007/12/12(水) 12:32:170715デフォルトの名無しさん
2007/12/12(水) 13:45:33開発完了したら、一番上でキャッチしてメッセージを出して終了するようにする
まあ使われないのが理想だが
0716デフォルトの名無しさん
2007/12/12(水) 14:43:31問題は、デバッガがthrow;でブレークして、
例外が投げられた瞬間のブレークが失われることだ
例外が投げられた瞬間のブレークがあれば何が間違っていたか大抵全部分かる
それを捨てる理由になると思うか？
0717デフォルトの名無しさん
2007/12/12(水) 15:29:090718デフォルトの名無しさん
2007/12/12(水) 15:34:07その作業は無駄だし
例外が起きなくてもその行で毎回止まるぞ
0719デフォルトの名無しさん
2007/12/12(水) 15:38:47BitmapImage image2 = new BitmapImage();
...
...
...
.
って一つずつ書くのが面倒なんですが、まとめて書ける方法ってありますか？
0720デフォルトの名無しさん
2007/12/12(水) 15:44:55配列にしてループ
0721デフォルトの名無しさん
2007/12/12(水) 15:57:550722デフォルトの名無しさん
2007/12/12(水) 16:02:12自分で考えられないやつは2chなんか使うな
0723デフォルトの名無しさん
2007/12/12(水) 16:07:15>>1
0724デフォルトの名無しさん
2007/12/12(水) 16:49:020725デフォルトの名無しさん
2007/12/12(水) 16:52:140726デフォルトの名無しさん
2007/12/12(水) 16:53:460727デフォルトの名無しさん
2007/12/12(水) 16:57:080728デフォルトの名無しさん
2007/12/12(水) 16:57:48続行できないから例外投げてるのに戻してどうすんの
だいたいなんで正常に戻せたってわかるの? クラスやメソッドの実装によるだろそんなの
0729デフォルトの名無しさん
2007/12/12(水) 17:10:27それはもともと例外を投げるべきではなかったんじゃないか
0730デフォルトの名無しさん
2007/12/12(水) 17:11:560731デフォルトの名無しさん
2007/12/12(水) 17:13:360732デフォルトの名無しさん
2007/12/12(水) 17:17:030733デフォルトの名無しさん
2007/12/12(水) 17:20:30{
ケーブルが抜けていたとか
ディスクの入れ忘れとか
電源入れ忘れとか
}
catch
{
えらー表示した
対処された
}
そんな感じの場合なんだけど
0734デフォルトの名無しさん
2007/12/12(水) 17:23:52とりあえずキャッチしておけば実行停止することはないんだからあとは君の判断で
0735デフォルトの名無しさん
2007/12/12(水) 17:28:04try {
例外の起きる処理;
break; // 完了
} catch ( .. ) {
if ( ! Retry ) break;
}
}
0736デフォルトの名無しさん
2007/12/12(水) 17:31:450737デフォルトの名無しさん
2007/12/12(水) 17:32:53{
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{
ケーブルが抜けていたとか
ディスクの入れ忘れとか
電源入れ忘れとか
}
catch
{
ケーブルを挿すとか
ディスクを入れるとか
電源を入れるとか
}
0739デフォルトの名無しさん
2007/12/12(水) 17:46:250740デフォルトの名無しさん
2007/12/12(水) 17:58:220741デフォルトの名無しさん
2007/12/12(水) 18:07:43リトライが必要な処理群としてまとめておいて呼び出し側で再呼び出しした方がｲｸﾅｲ？
0742デフォルトの名無しさん
2007/12/12(水) 18:08:33ソースコードで頼む
0743デフォルトの名無しさん
2007/12/12(水) 18:10:190744デフォルトの名無しさん
2007/12/12(水) 18:11:34有り得ない値返し
エラーコード返し
BOOL返し
HRESULT返し
C++の例外
.netの例外
構造化例外
が入り乱れるVCよりましじゃないか。
0745デフォルトの名無しさん
2007/12/12(水) 18:12:00分岐では分かりにくくなることが往々にしてある
0746デフォルトの名無しさん
2007/12/12(水) 18:23:010747デフォルトの名無しさん
2007/12/12(水) 18:40:44dim 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:14public 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:01object型を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:11InvalidCastExceptionをそのまま捕まえるのはいただけない
catchするのはバグによる例外でないことが明らかなものにするべきだ
エラー処理に何をするのか、DBNullが帰ってくる頻度がどのくらいで
例外がパフォーマンスに影響するのかによって変わってくる
0751デフォルトの名無しさん
2007/12/12(水) 19:14:01たしかに、NULLが入ってるデータが多いと使い物にならないくらい遅くなりますね。
それでは、基本的にNULLは入ってないデータだけど、NOT NULL制約がないので「NULLもありえる」という
程度で。
例外は>>748みたいなラッパーで、独自のものを投げるという状況で。
ifでチェックしたほうがいいか、まとめて例外で処理したほうがいいか。
0752デフォルトの名無しさん
2007/12/12(水) 19:15:170753デフォルトの名無しさん
2007/12/12(水) 19:35:51{
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:32return new Uri("error://imifumei/");
みたいな感じで返すのはありですか？
0756デフォルトの名無しさん
2007/12/12(水) 19:46:45public 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なしです
例外またはTry〜を使いなさい
0759デフォルトの名無しさん
2007/12/12(水) 20:09:41nullを返すのは?
0760デフォルトの名無しさん
2007/12/12(水) 20:10:33個人的には、名前の末尾にOrNullをつけないとなしと考えている
つければあり
0761デフォルトの名無しさん
2007/12/12(水) 20:14:190762デフォルトの名無しさん
2007/12/12(水) 20:16:430763デフォルトの名無しさん
2007/12/12(水) 20:19:56それにテスト後にｍａｉｎにtry〜catch追加したらテストやり直しだろ
異常系のテストエビデンスに再現性無くなるじゃん
個人作成やパッケージ等すべて自分達で責任取れるものならいいけどさ
0764デフォルトの名無しさん
2007/12/12(水) 20:21:34見たことも聞いたこともない命名規則だな。
0765デフォルトの名無しさん
2007/12/12(水) 20:22:07どっちだよｗ
0766デフォルトの名無しさん
2007/12/12(水) 20:25:020767デフォルトの名無しさん
2007/12/12(水) 20:26:510768デフォルトの名無しさん
2007/12/12(水) 20:27:05バグじゃなくて仕様の中に処理するって書いてある例外は開発中ももちろんキャッチする
問題はそれ以外だ
それ以外が飛んできたらバグだ
これは開発完了したときには飛んでくることがないのが理想だけど
そうもいってられないのでcatch(Exception)で捕まえる文を開発完了後に付け加える
で、謝罪文を表示して終了すればいい
これをテストする必要は別にない
0769デフォルトの名無しさん
2007/12/12(水) 20:27:430770デフォルトの名無しさん
2007/12/12(水) 20:28:52First
FirstOrDefault
といった感じでデフォルト値が返りうる場合はOrDefaultをつける
OrNullって書いてなきゃ絶対にnulのチェックを忘れるから俺はOrNullと書くべきだと考えている
0771デフォルトの名無しさん
2007/12/12(水) 20:30:39多分噛み合ってないんだけど
納品先のあるプログラムでテスト後にソース改変は一切NGだろ？
バイナリのタイムスタンプとCRCが一致しないテスト結果でもOKってなら
何も言えないな
0772デフォルトの名無しさん
2007/12/12(水) 20:35:00じゃあ付け加えなきゃいい
万一の場合に備えて例外のメッセージを丁寧語にすることを心がけなきゃならんが
ちゃんと出来てるならほんとはcatch(Exception)なんていらん
0773デフォルトの名無しさん
2007/12/12(水) 20:41:28エラーかもね。
たぶんお前らのミスな。
[OK]
0774デフォルトの名無しさん
2007/12/12(水) 20:42:34>ちゃんと出来てるならほんとはcatch(Exception)なんていらん
これはマじゃない予感・・・
0775デフォルトの名無しさん
2007/12/12(水) 20:47:31また噛み合ってないが、バグ０にはできない。現実的に。
だから「ちゃんとできている」って言うのは実現困難
当然メソッド単位にtry〜catch入れた上での単体テストを通してるし
mainにも付け加えないんじゃ無くて最初から入れてる
たとえプログラムが原因じゃなくてもトラップできる例外はすべて
プログラムの管理しているエラー処理＋ログで処理する
それを元に障害対応しないと対応できない
リリース後に 「プログラムのせいかどうかわからんがエラー終了する」
なんて状況になったら誰が対応するの？
自分達のプログラムが原因じゃない証明をする際にも証拠は必要だし
0776デフォルトの名無しさん
2007/12/12(水) 20:49:28今度イベントあったら絶対見に行くわ
0777デフォルトの名無しさん
2007/12/12(水) 20:54:17出来ました、テストしてください、という段階でmainにcatch(Exception)を付け加える
それじゃダメなのか？
0778デフォルトの名無しさん
2007/12/12(水) 21:16:30ttp://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:080781デフォルトの名無しさん
2007/12/12(水) 22:26:28うまく行ってるのを見たことがない。
現実の開発要員は思いのほかレベルが低いもんだよ。
保守や改造でもどんどん壊れて行くしね。
十分な費用がかけられる開発ならいいんだけどね〜
0782デフォルトの名無しさん
2007/12/12(水) 22:27:31全て処理せよってのはどういうこっちゃ
0783デフォルトの名無しさん
2007/12/12(水) 22:37:070784デフォルトの名無しさん
2007/12/12(水) 22:41:21正しく呼び出したとしても起こる例外→キャッチしなければならない
0785デフォルトの名無しさん
2007/12/12(水) 22:53:59http://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:230787デフォルトの名無しさん
2007/12/12(水) 23:01:15有るはずのファイルが読めなければ
キャッチする必要があるのだろうが、
渡された引数がそもそも間違ってた場合は
キャッチしちゃダメだってことだなｗ
0788デフォルトの名無しさん
2007/12/12(水) 23:05:54キャスト失敗とか配列の外側を読んだとかぬるぽとか
そういうのは全部キャッチしちゃダメ
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γ線でメモリが化けたのか分からない。
0793デフォルトの名無しさん
2007/12/12(水) 23:12:14じゃないとわからん
0794デフォルトの名無しさん
2007/12/12(水) 23:16:10結局回復できない場合も多いから、戻り値とかで返さざるを得ないの？
UI層レベルでは想定されるものはキャッチするだろうけど
もっと下層ではいかんともしがたい気がする。
0795デフォルトの名無しさん
2007/12/12(水) 23:17:00コード中で直接設定したりする方法があるのですがどういう風に使い分ければいいんですか？
0796デフォルトの名無しさん
2007/12/12(水) 23:17:55キャッチしてエラーメッセージを出して入力待ちに戻れ
0797デフォルトの名無しさん
2007/12/12(水) 23:18:48ドキュメントコメントでいい気もする。
あ、レビューはやりにくいかな…
0798デフォルトの名無しさん
2007/12/12(水) 23:20:12もっと下層ではどうすんの？
0799デフォルトの名無しさん
2007/12/12(水) 23:21:12null入れていいかどうか、nullが返るかどうかなんて一回見たってどうせ忘れる
OrNullって書いてあればソース見ただけでnullチェックして無いのが一発でバグって分かる
0800デフォルトの名無しさん
2007/12/12(水) 23:21:530801デフォルトの名無しさん
2007/12/12(水) 23:22:23特に理由がなければデザイナを使う
動的(例:ボタンを押したら〜する)にコントロールを作ったり、プロパティを変更したいときはコードで
0802デフォルトの名無しさん
2007/12/12(水) 23:23:01自分のメソッドの仕様に書いてある通りの例外に編み変えて再スローする
0803デフォルトの名無しさん
2007/12/12(水) 23:23:190804デフォルトの名無しさん
2007/12/12(水) 23:25:25呼ばれる側もそうだし呼ぶ側もそうだ
OrNullって書くようにしてからnullチェックし忘れは消えた
0805デフォルトの名無しさん
2007/12/12(水) 23:25:37言いたかったのはそんだけちゃんとやっても呼び出し側のバグに対しては効果ないよねってこと。
0806デフォルトの名無しさん
2007/12/12(水) 23:27:13nullチェックはどっちの場合でも要るんじゃ…
0807デフォルトの名無しさん
2007/12/12(水) 23:28:42なるほど、初期設定はデザイナでして実行中の変更はコードでするみたいな感じですね。
0808デフォルトの名無しさん
2007/12/12(水) 23:29:00呼び出し側の引数かなんかの違反なら
呼び出し側の違反ですよってわかる例外を投げる
正しく呼び出したときの例外ならそれと分かる例外を投げる
さらに下のメソッドから飛んでくる例外がそこをきちんと分けていれば
自分も判断できる
■ このスレッドは過去ログ倉庫に格納されています