ふらっとC#,C♯,C＃（初心者用） Part21
■ このスレッドは過去ログ倉庫に格納されています
0001ななしぃ#
2007/11/18(日) 15:53:41「どんなにくだらないC#プログラミングに関する発言でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問など、
勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。
前スレ: ふらっとC♯, C＃（初心者用） Part20
http://pc11.2ch.net/test/read.cgi/tech/1191036844/
0655335
2007/12/11(火) 20:03:11{
Aaa(p1);
}
catch (HogeException e)
{
Console.WriteLine("{0} HogeException caught.", e);
}
catch
{
throw;
}
こんなふうに投げちゃいかんの？
メソッドやクラス内で処理する分はcatchしてそれ以外は上に投げる
投げ先が制御できないなら共通エラー処理クラス使えばいいと思うんだけど
初めて１週間なんでハズしてたら教えて欲しいです
0656デフォルトの名無しさん
2007/12/11(火) 20:03:540657デフォルトの名無しさん
2007/12/11(火) 20:06:54デバッガはthrow;のところで止まって例外が投げられた瞬間の情報が失われるけど
それでいいなら
それを避けたければデバッグ→例外を選んで投げた瞬間にブレイクしてほしい
例外にチェックをつけてもいい
0658デフォルトの名無しさん
2007/12/11(火) 20:13:010659デフォルトの名無しさん
2007/12/11(火) 20:14:460660デフォルトの名無しさん
2007/12/11(火) 20:15:150661デフォルトの名無しさん
2007/12/11(火) 20:18:490662デフォルトの名無しさん
2007/12/11(火) 20:38:38確かに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某首相の中の人とかか?
0666デフォルトの名無しさん
2007/12/11(火) 21:17:06諦めな
もし隔離スレを埋めたいのであればそっちにネタ投下すればいい
0667デフォルトの名無しさん
2007/12/11(火) 21:27:39どうせCOBOLでやるような糞仕事をリプレースしただけだろ
0668デフォルトの名無しさん
2007/12/11(火) 21:32:320669デフォルトの名無しさん
2007/12/11(火) 23:01:190670デフォルトの名無しさん
2007/12/11(火) 23:05:000671デフォルトの名無しさん
2007/12/11(火) 23:06:510672デフォルトの名無しさん
2007/12/11(火) 23:07:020673デフォルトの名無しさん
2007/12/11(火) 23:08:380674デフォルトの名無しさん
2007/12/11(火) 23:17:110675デフォルトの名無しさん
2007/12/12(水) 00:00:35それを使うなって┐(´д｀)┌
0676デフォルトの名無しさん
2007/12/12(水) 00:10:23バグを通知するためにはものすごく必要だ
エラーで分岐するにはそのままでは不適切な仕組みだ
適切に使わないといけない
0677デフォルトの名無しさん
2007/12/12(水) 00:18:470678デフォルトの名無しさん
2007/12/12(水) 00:27:11今から始めるなら当然WPFアプリが良いんだよね？
0679デフォルトの名無しさん
2007/12/12(水) 00:36:020680デフォルトの名無しさん
2007/12/12(水) 00:36:290681デフォルトの名無しさん
2007/12/12(水) 00:49:00例外で処理分岐する場合もあれば、戻り値でも処理分岐する場合あるし臨機応変
0682デフォルトの名無しさん
2007/12/12(水) 00:51:15例外ハンドラが見つかるまで積まれたスタックフレームをすっとばす。
0683デフォルトの名無しさん
2007/12/12(水) 00:53:32俺なんか自分で作ったクラスは
try catchでcatchしたらthrowだよ。
でaspx.csで例外を受け取ったらRedirectでエラーページに遷移させる。
社内システムなんでそんなもんだぜ。
0684デフォルトの名無しさん
2007/12/12(水) 00:54:46それは臨機応変じゃなくて規約がなくその都度注意力をもって判断せねばならず
バグかどうかがドキュメントを参照しないと分からないということだろう
最悪の方法だ
0685デフォルトの名無しさん
2007/12/12(水) 00:58:45必要なエラーメッセージを出すようにすればいいさ
しかし開発中はバグの例外はキャッチしちゃいかんのだ
0686デフォルトの名無しさん
2007/12/12(水) 01:03:09VB.NET使う必要も技術的利益も無いんだがな・・・
なんでVB.NET選ぶかね・・・
0687デフォルトの名無しさん
2007/12/12(水) 01:08:47エラーメッセージ無視して「デバッガで追おうとしたけど再現しません」とかいう奴すら・・・
0688デフォルトの名無しさん
2007/12/12(水) 01:12:31エラーメッセージなんて例外で適切にブレイクできてりゃ最小限でいいんだ
0689デフォルトの名無しさん
2007/12/12(水) 01:17:09エラーかどうかは殆どの場合ドキュメント見るんじゃないの？
0690デフォルトの名無しさん
2007/12/12(水) 01:19:150691デフォルトの名無しさん
2007/12/12(水) 01:22:52と決めておけば、それをキャッチしておけばいい
例外がキャッチできずすり抜けていったら呼び出し側のミスだ
向こう側が間違ってるのかもしれないがその時はドキュメントをよく読んで質問するしかない
0692デフォルトの名無しさん
2007/12/12(水) 01:26:13例外だと中断されるのですよね？こんな場合は戻り血とかで判断するのですか
0693デフォルトの名無しさん
2007/12/12(水) 01:36:59そういえば正しい方法を言ってなかった気がする
catch
{
throw;
}
これはいらないからなくすべき
例外が投げられた瞬間の情報が失われるから
0694デフォルトの名無しさん
2007/12/12(水) 01:41:370695デフォルトの名無しさん
2007/12/12(水) 01:42:53そりゃそうだ
0696デフォルトの名無しさん
2007/12/12(水) 01:42:55http://msdn2.microsoft.com/ja-jp/library/ms229014.aspx
0697デフォルトの名無しさん
2007/12/12(水) 01:45:450698デフォルトの名無しさん
2007/12/12(水) 01:49:340699デフォルトの名無しさん
2007/12/12(水) 01:51:230700デフォルトの名無しさん
2007/12/12(水) 01:59:480701デフォルトの名無しさん
2007/12/12(水) 02:02:26必ずってどのレベルで必ずなの？
メソッド呼び出し全部？
catchしてその場でどうにかできるのなんて一部な気がするんだが。
まあラップして投げなおしはあるかもしれんが。
そうでなくみんな戻り値とかでエラー返して上位に通知してるなら
それこそ単純に例外ですむ話し出しってか上位への通知を細かに書かなくてすむ
ってのが例外のメリットのひとつだと思うんだが、
多分そういうことではないんだよね？
0702デフォルトの名無しさん
2007/12/12(水) 02:04:13その場で処理してしまうような例外は別だけど。
0703デフォルトの名無しさん
2007/12/12(水) 02:09:29＞たとえば、ファイルが見つからない場合には 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:490706デフォルトの名無しさん
2007/12/12(水) 04:10:42ログやメッセージ出してアプリを中断が常套。MSのガイドラインでもこうなってるな。
0707デフォルトの名無しさん
2007/12/12(水) 04:41:05その上に構築するアプリケーションにおける例外のデザインの話は
分けて考えないと論点がはっきりしない気がするな。
0708デフォルトの名無しさん
2007/12/12(水) 05:44:24と
ProfessionalColors.ImageMarginGradientBegin
の違いって何ですか？
ImageMarginRevealedGradientBeginは、どういう場合に使われますか？
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/");
みたいな感じで返すのはありですか？
■ このスレッドは過去ログ倉庫に格納されています