トップページ⇒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/
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
それがバグじゃなくて想定内のものなら
キャッチしてエラーメッセージを出して入力待ちに戻れ
0797デフォルトの名無しさん2007/12/12(水) 23:18:48
OrNullつけても結局仕様確認はいるんだから
ドキュメントコメントでいい気もする。
あ、レビューはやりにくいかな…
0798デフォルトの名無しさん2007/12/12(水) 23:20:12
>>796んなこと出来るのはUI層ぐらいだろう。
もっと下層ではどうすんの？
0799デフォルトの名無しさん2007/12/12(水) 23:21:12
>>797
null入れていいかどうか、nullが返るかどうかなんて一回見たってどうせ忘れる
OrNullって書いてあればソース見ただけでnullチェックして無いのが一発でバグって分かる
0800デフォルトの名無しさん2007/12/12(水) 23:21:53
下層じゃ呼ぶ側の問題なのか本当の例外事象なのかなんて分からないんだぜ？
0801デフォルトの名無しさん2007/12/12(水) 23:22:23
>>795

特に理由がなければデザイナを使う
動的(例:ボタンを押したら〜する)にコントロールを作ったり、プロパティを変更したいときはコードで
0802デフォルトの名無しさん2007/12/12(水) 23:23:01
>>798
自分のメソッドの仕様に書いてある通りの例外に編み変えて再スローする
0803デフォルトの名無しさん2007/12/12(水) 23:23:19
あえ？呼ばれる側でのnullチェックの話か？
0804デフォルトの名無しさん2007/12/12(水) 23:25:25
>>803
呼ばれる側もそうだし呼ぶ側もそうだ
OrNullって書くようにしてからnullチェックし忘れは消えた
0805デフォルトの名無しさん2007/12/12(水) 23:25:37
>>802まあそうなるんだけど
言いたかったのはそんだけちゃんとやっても呼び出し側のバグに対しては効果ないよねってこと。
0806デフォルトの名無しさん2007/12/12(水) 23:27:13
nullチェックし忘れって
nullチェックはどっちの場合でも要るんじゃ…
0807デフォルトの名無しさん2007/12/12(水) 23:28:42
>>801
なるほど、初期設定はデザイナでして実行中の変更はコードでするみたいな感じですね。
0808デフォルトの名無しさん2007/12/12(水) 23:29:00
>>805
呼び出し側の引数かなんかの違反なら
呼び出し側の違反ですよってわかる例外を投げる
正しく呼び出したときの例外ならそれと分かる例外を投げる
さらに下のメソッドから飛んでくる例外がそこをきちんと分けていれば
自分も判断できる
0809デフォルトの名無しさん2007/12/12(水) 23:35:08
結局、呼び出し側の要因であっても何であっても
エラー発生時の対処は必要なんだから全て例外処理が
必要ってことおｋ？
0810デフォルトの名無しさん2007/12/12(水) 23:35:45
非null引数なら入ってくるときにnullをはじけばいいのだが
nullを受け入れて変数に入れた場合は、その変数を使うたびにnullチェックが要る
変数名にOrNullって書いてあればチェックし忘れはなくなる
0811デフォルトの名無しさん2007/12/12(水) 23:40:29
そもそも引数でnull渡すケースってあるの？
0812デフォルトの名無しさん2007/12/12(水) 23:40:42
>>809
呼び出し側の要因である場合必要な処置というのは
バグを認識させ直させることだ
キャッチしなければそれが最もよく果たせる
例外が投げられた瞬間でデバッガがブレイクし何が間違っていたかが分かる
0813デフォルトの名無しさん2007/12/12(水) 23:41:35
>>812
Trace吐けばいいのでは
0814デフォルトの名無しさん2007/12/12(水) 23:44:59
>>813
マウスポインタおいたら変数の値がぱっとわかり
呼び出し履歴をずずっと辿っていくこともできるようなトレースならな
0815デフォルトの名無しさん2007/12/12(水) 23:47:03
>>786

MatchCollection mc = Regex.Matches(hoge.ToLower(), @"(http/1.[0-1] 200)|(https?://.*\.xml)");
if (mc.Count < 2)
{
　// 異常
}
0816デフォルトの名無しさん2007/12/12(水) 23:47:49
バグ対処には例外処理せず.NETの例外画面で・・・なんて人は趣味グラマーなんだよ
そんな画面出しても済ませられる程度のAPなんだ
0817デフォルトの名無しさん2007/12/12(水) 23:49:06
>>808それが呼ばれる側では判断できないって話じゃないのか？
0818デフォルトの名無しさん2007/12/12(水) 23:49:16
>>816
多分、昨日からずっとそのこと言ってる人いますね
0819デフォルトの名無しさん2007/12/12(水) 23:49:45
お前ら本当に例外が好きだなw
0820デフォルトの名無しさん2007/12/12(水) 23:50:01
判断できるなら分岐処理でいいので例外は不必要でしょう
0821デフォルトの名無しさん2007/12/12(水) 23:50:55
俺は例外で、この話題飽きたお　早く次のネタ投下して欲しいお
0822デフォルトの名無しさん2007/12/12(水) 23:51:48
すみません！リストビューの行の高さは変えられますか？
0823デフォルトの名無しさん2007/12/12(水) 23:52:39
>>817
なんで判断できないんだ？
メソッドの正しい呼び出し方を決めるのは自分だぞ
0824デフォルトの名無しさん2007/12/12(水) 23:52:59
ファイルが見つからない例外が発生したとき、
それがバグなのかそうでないのかなんて判断できない。
0825デフォルトの名無しさん2007/12/13(木) 00:01:08
>>824
呼び出し方自体はあってるなら
FileNotFoundExceptionを投げればいい

パス文字列として正しくないならInvalidPathExceptionかなんかを投げればいい
メソッド作成者が、パス文字列として正しくない文字列を渡すのが違反だと考えるなら
ArgumentExceptionにしてもいい
もちろんパス文字列として正しいかどうかを判断する方法は別途用意しなきゃならないし
それを判断してから呼び出すのは無駄だから普通は
パス文字列として正しくないものも違反とは考えないという設計にするだろうが

呼び出し側はパス文字列として正しくないのが渡されるのがバグである場合はキャッチしなければいいし
ユーザーが入力したのをそのまま渡すとかするならキャッチしなきゃいけない
0826デフォルトの名無しさん2007/12/13(木) 00:02:16
それってふ#[email protected]?
0827デフォルトの名無しさん2007/12/13(木) 00:04:26
ファイルが存在しないときにArgumentExceptionを投げる関数もあるので、
ArgumentExceptionは一概に呼び出し側の要因とは言えない。
エラーチェックしろって話だが。
0828デフォルトの名無しさん2007/12/13(木) 00:06:50
それってぁいるはんどるつくるときにかってにかえってこないか？
0829デフォルトの名無しさん2007/12/13(木) 00:09:07
>>827
どれだよ
正しくない呼び出しと区別できないんだったらそれはただの設計ミスだ
0830デフォルトの名無しさん2007/12/13(木) 00:11:44
FileSystemWatcher.Pathだ、まいったかこの野郎。
まぁファイルの存在確認もしない奴は死んだ方が良いけど。
0831デフォルトの名無しさん2007/12/13(木) 00:14:19
呼び出し側が正しいけどファイルがないときと
呼び出し側が間違っててファイルがないときがあるだろ。
そんなの呼び出される側じゃ分からない。
結局同じ例外なり返さざるを得ない。
0832デフォルトの名無しさん2007/12/13(木) 00:14:44
>>830
そりゃパスを入れるプロパティにパスじゃないものが入ったらArgumentExceptionだろ
そりゃ違反だ
0833デフォルトの名無しさん2007/12/13(木) 00:15:08
>>830
それの後にファイルが消失したら？
0834デフォルトの名無しさん2007/12/13(木) 00:16:22
どっちにしてもtryは全て必要ってことで
0835デフォルトの名無しさん2007/12/13(木) 00:16:54
Tryは有害
0836デフォルトの名無しさん2007/12/13(木) 00:19:28
>>831
そりゃそうだな
メソッドに出来るのは自分が決めたルールに違反を犯したかどうかを通知するだけだ
0837デフォルトの名無しさん2007/12/13(木) 00:21:51
有名どころですら統一見解だせないものをここでぐだぐだ議論してもね。
0838デフォルトの名無しさん2007/12/13(木) 00:23:42
tryはしてもいいが全てをキャッチするのは誤りだ
キャッチしていいものと、しちゃいけないものがある
0839デフォルトの名無しさん2007/12/13(木) 00:24:33
>>832
パスが不正かどうかはファイルが存在するしないに関係しないだろ。
こういうのはDirectoryNotFoundExceptionを返すケース。
0840デフォルトの名無しさん2007/12/13(木) 00:27:27
>>839
＞ArgumentException
＞
＞指定したパスにワイルドカード文字が含まれています。
＞または
＞指定したパスに無効なパス文字が含まれています。
http://msdn2.microsoft.com/ja-jp/library/system.io.filesystemwatcher.path(VS.80).aspx

と書いてあるがこれは間違いか？
0841デフォルトの名無しさん2007/12/13(木) 00:35:15
おろ？うちのMSDNにはこうあるけど。

>指定されたパスが存在しないか、見つかりませんでした。
>または
>指定したパスにワイルドカード文字が含まれています。
>または
>指定したパスに無効なパス文字が含まれています。
0842デフォルトの名無しさん2007/12/13(木) 00:40:58
>>841
パスが無効とNot Foundとnullとは
分けた方がいいと思うんだがなあ
まあそんなに困るケースは思いつかないが
0843デフォルトの名無しさん2007/12/13(木) 00:44:59
catchしないで実行時エラー出るようなプログラムは駄目だろ
0844デフォルトの名無しさん2007/12/13(木) 00:47:11
>>843
完成版には一番上にcatch(Exception)入れなきゃいかんだろうが
開発中はいれちゃいかんという話だ
想定外の例外が来たら安全に実行が続けられるかなんて分からんのだから
終了するしかない
0845デフォルトの名無しさん2007/12/13(木) 00:49:11
障害系の単体テスト結果はどうするの？
0846デフォルトの名無しさん2007/12/13(木) 00:54:20
例外祭り終了
0847デフォルトの名無しさん2007/12/13(木) 00:54:21
>>845
どういう意味か分からんが
単体テストなら正しい例外が返ってくるかcatchして調べる
想定外の例外が返ってきたらバグだからそれはcatchしない
0848デフォルトの名無しさん2007/12/13(木) 01:12:42
もう余所でやってくれ
質問者がスルーされまくってるだろ
どれが質問者から分からないくらいに
0849デフォルトの名無しさん2007/12/13(木) 04:31:09
例外をcatchするとデバッグしにくいという問題は簡単に回避できる。
その答えは・・・続きはこちらで、みんな移動頼む。
C♯, C＃相談室 Part34
http://pc11.2ch.net/test/read.cgi/tech/1162467959/507-
0850デフォルトの名無しさん2007/12/13(木) 09:28:16
エスケープシーケンス文字ってどうして%とか\とか{}つかうの？
もっと存在しない記号にすれば良いのに
■ このスレッドは過去ログ倉庫に格納されています