トップページ⇒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/
0556デフォルトの名無しさん2007/12/09(日) 22:57:20
と、いうわけでアクセス修飾子の話でも。

public　何処からでもアクセス可能(アクセスレベルが低いと表現)
↑
protected　派生クラスはアクセス可能
↓
private　自分しか無理。(アクセスレベルが高い)

クラスAにposX、posY、graphic、というフィールドがあれば、
クラスAを継承したクラスBも、そのフィールドを持つ。
それらのフィールドのアクセスレベルをprotectedにしておけば、派生クラスでもフィールドに自由に代入・取り出しできる。
もしprivateだと、それぞれフィールドは存在するのに一切派生クラスからはアクセスできない、ということになる。
この場合はプロパティを基本クラスで作っておけばすれば解決できる。(というかgetとsetのアクセスレベルを分けるから大抵はこっち？かな)




0557デフォルトの名無しさん2007/12/09(日) 23:00:22
フィールドをprotectedにしちゃうのはお勧めできない
初期化はたいてい基底クラスのコンストラクタを呼べば済む
0558デフォルトの名無しさん2007/12/10(月) 00:07:18
継承なんてすんなよ。
0559デフォルトの名無しさん2007/12/10(月) 04:22:03
てか、フィールドをprotectedにするのは禁止じゃなかったか。
プロパティなら良い。
0560デフォルトの名無しさん2007/12/10(月) 10:27:11
誰が？
0561デフォルトの名無しさん2007/12/10(月) 10:29:23
オレオレ
0562デフォルトの名無しさん2007/12/10(月) 11:25:16
とある機器からUDPでHTTP1.1なデータを送ってくるのですが
受信と解析するようなクラスはありますか？
0563↑2007/12/10(月) 11:28:01
受信だけはUdpClientでできるんですけど
0564デフォルトの名無しさん2007/12/10(月) 11:33:59
WebClient
0565デフォルトの名無しさん2007/12/10(月) 12:09:29
>>561
ttp://nasu.x0.com/blog/program/index_2.html
0566デフォルトの名無しさん2007/12/10(月) 15:03:48
例外が起こる前にifで避けるのと、起こってからtry-catchで対応するのとどっちがいいですか？
こういう時はtry-catchを使うという判断基準ってあるのでしょうか？
0567デフォルトの名無しさん2007/12/10(月) 15:09:44
モノによるけど私はifで避けれることはifで避けるようにしてる。
try-catchでしか回避できない仕様なら仕方なしに使う感じ
0568デフォルトの名無しさん2007/12/10(月) 15:29:29
例外をキャッチするとわけわかんなくなるから
ifで出来るものはifでやった方がいいよな
ArgumentExceptionとか例外が投げられること自体がバグの証明であるようなのは
どんどん投げるべき
そしてキャッチさせないべき
そのためにtryで囲ませないべき
tryで囲ませると往々にしてバグまで握りつぶしてしまう
05695662007/12/10(月) 15:57:42
事前に避けられそうな奴は避けるべきなんですね。
早速コード直してみます。
ありがとうございました。
0570デフォルトの名無しさん2007/12/10(月) 16:12:28
教えてください。
WebBrowserコントロールで、
Internet Explorer の [ファイル] メニューの [名前を付けて保存] メニュー オプションのような
機能を実装しようとしているのですが、
以下のようなコードですとエラーがでます。
どうすればいいんでしょう。。。

AxWebBrowser3.ExecWB( ShDocVw.OLECMDID_SAVEAS, ShDocVw.OLECMDEXECOPT.OLECMDEXECOPT_DODEFAULT);ですと
'ShDocVw' は現在のコンテキスト内に存在しません。
とエラーがでてしまったのですが。。。

0571デフォルトの名無しさん2007/12/10(月) 17:31:41
using ShDocVw;
0572デフォルトの名無しさん2007/12/10(月) 17:32:55
OLECMDID.OLECMDID_SAVEAS
0573デフォルトの名無しさん2007/12/10(月) 18:29:19
using ShDocVw;を追加したのですが以下のエラーが出ました。
型または名前空間名 'ShDocVw' が見つかりませんでした。
using ディレクティブまたはアセンブリ参照が不足しています。
0574デフォルトの名無しさん2007/12/10(月) 19:20:05
コントロールを削除してもソースにイベントハンドラが残るんですけど手動で削除するしかないんですか？
0575デフォルトの名無しさん2007/12/10(月) 19:44:30
勝手に消えても困るだろ？
0576デフォルトの名無しさん2007/12/10(月) 20:05:55
ほかから参照されていないとかの条件なら消すかどうかの選択肢はあってもいいかもね
0577デフォルトの名無しさん2007/12/10(月) 20:46:51
>>573
shdocvw.dll参照にいれたんじゃなくてWebBrowserコントロールか。

ShowSaveAsDialog ってメソッドがあるでしょ。
0578デフォルトの名無しさん2007/12/10(月) 21:18:12
ShowSaveAsDialog();は、AxWebBrowserにはないみたいです。
shdocvw.dllは、参照にいれる必要ないんですか？
0579デフォルトの名無しさん2007/12/10(月) 21:37:12
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=42629&forum=7
0580デフォルトの名無しさん2007/12/10(月) 21:42:19
どっちかの質問取り下げろやハゲ
0581デフォルトの名無しさん2007/12/10(月) 22:41:02
WebBrowserコントロールと書いておきながらaxWebBrowserなのか？
0582デフォルトの名無しさん2007/12/10(月) 23:05:26
>>566
おれはめちゃくちゃcatchしまくってるよ。
おかげでエラーチェックのifが少なくなって、ロジックが超すっきり。
0583デフォルトの名無しさん2007/12/10(月) 23:09:29
ifやめてcatchにする方が
どう繋がってるのか分かりにくい
0584デフォルトの名無しさん2007/12/10(月) 23:12:50
catchの方がコスト高いでしょ？
0585デフォルトの名無しさん2007/12/10(月) 23:19:28
たとえば、CSVを読み込んで、DBに入れるコードを書くとして、
TryPerse() でなくて、Prese()で、intに変換。
FormatExceptionが飛んだら、このCSVは不正ですって言って、処理終了。

これでなんにも問題ありません。
0586デフォルトの名無しさん2007/12/10(月) 23:21:09
まあ終了する時は例外ほど便利なものはない
0587デフォルトの名無しさん2007/12/10(月) 23:53:12
趣味グラマか
0588デフォルトの名無しさん2007/12/10(月) 23:56:38
エラーコードはまだいいけど
null返してきたりスルーしやがるメソッドはうざい
0589デフォルトの名無しさん2007/12/11(火) 00:04:21
nullを返すのとbool TryHoge(out result)と例外返すのとどれがいい
0590デフォルトの名無しさん2007/12/11(火) 00:13:41
s@;w@mee;@s4ezdwh;
0591デフォルトの名無しさん2007/12/11(火) 00:42:53
例外
0592デフォルトの名無しさん2007/12/11(火) 00:43:34
TryParseよりParseがいいってか
0593デフォルトの名無しさん2007/12/11(火) 00:47:03
メソッドが不可避な例外を投げる場合、キャッチしなければバグになるわけだ
そしてそれがバグであるかどうかはドキュメントをよく読まないと分からない
TryHogeならばifで囲まれていない時点でバグであることが見た瞬間に分かる
どっちがいいかは分かりきっている
0594デフォルトの名無しさん2007/12/11(火) 01:22:57
というか、これは自分の想像だから間違ってたらただして欲しいんだけど、
昔のCの、intでエラーコードを返すタイプの関数から、
今の、voidでエラーが起きたときは例外を投げるタイプのメソッドに推移というか、
後者が主になったのは、なんらかの理由があるからじゃないの？
TryParseとかはその流れに逆行してるように感じたんだけど…
0595デフォルトの名無しさん2007/12/11(火) 01:25:42
そりゃ、TryParseのほうがタイプ量少なくて済むからな。軽いし。
ただし、boolを返すTryXxxを作るときは、例外を投げるXxxも用意することになってる。
0596デフォルトの名無しさん2007/12/11(火) 01:34:04
例外には2種類あって、ArgumentExceptionのように投げられること自体が呼び出し側の
ミスによるものであり、除去すべきバグであることが明らかなものと、
ネットワークのサーバがダウンしている、ファイルが存在しないといった
正しい呼び出し方をしたとしても起こりうるエラーがある
大半は前者だ。バグだから直さなきゃいけないというのを通知するのには例外は適している
失敗の可能性が不可避なメソッドならば、例外を用いずによりわかりやすいTry〜のような
形を用いるべきだ
Tryの形式なら一目でバグと分かるのに、わざわざ例外を使って
バグと分かりにくいコードを書かせる必要なんか皆無だ
どちらにもいえることだが、例外はキャッチするものでは無い
0597デフォルトの名無しさん2007/12/11(火) 01:50:28
要するにポリシーとしては、使い方に因らないエラーが発生する場合は例外を投げ、
使い方に因ってエラーが発生する場合は戻り値で返せということですかね？
0598デフォルトの名無しさん2007/12/11(火) 01:58:51
正しい呼び出しをしてない場合は例外を投げ
正しい呼び出しをしてもエラーが不可避である場合はboolかなんかを返せということを俺はいいたい
0599デフォルトの名無しさん2007/12/11(火) 02:01:03
君C#向いてないよ
0600デフォルトの名無しさん2007/12/11(火) 02:02:45
>>599
>>596のようにしない方がいい理由がなにかいえるのか？
0601デフォルトの名無しさん2007/12/11(火) 02:05:45
Try形式だと基本bool値しか返ってこないけど
エラーに関してもっと詳しい情報を渡したい時には>>596のスタンス的にはどういう方法をとるの？
戻り値？引数？
0602デフォルトの名無しさん2007/12/11(火) 02:06:52
あ、割り込んじゃったけど>>601≠>>599です
0603デフォルトの名無しさん2007/12/11(火) 02:08:06
>>601
outでエラーの詳しい情報をobjectにして戻すのがいいと思っているが
それこそ例外をoutで返したらいい
0604デフォルトの名無しさん2007/12/11(火) 02:15:27
.NetFrameworkでそういった作りになってる物があるかな。
0605デフォルトの名無しさん2007/12/11(火) 02:19:16
投げずに渡す、か
正直それは考えた事なかったな
0606デフォルトの名無しさん2007/12/11(火) 02:22:15
.NET FrameworkにはTryParseのような一部のものしかそういう設計をとっていない
それは誤りだが今さら変えられない
.NET Frameworkで例外を返すのが使い物になるのはそれが共通であり
プログラマなら大抵そのクラスの動作を知っているからだ
自作のクラスでそれをやるのは死亡フラグそのものだ
0607デフォルトの名無しさん2007/12/11(火) 09:47:13
日本語でおｋ
0608デフォルトの名無しさん2007/12/11(火) 10:17:45
文字列をint型にキャストするには
　int.Parse(hogehoge)
等の方法でやっていますが、
変換する型そのものを文字列等で指定する方法がありますでしょうか？
0609デフォルトの名無しさん2007/12/11(火) 11:43:08
結局Win32のカオス具合をなぞってるだけだな
0610デフォルトの名無しさん2007/12/11(火) 11:51:29
>>608
それはキャストじゃなくて型変換（Convert）だろ。
TypeConverter/TypeDescriptor でも使えば？
0611デフォルトの名無しさん2007/12/11(火) 12:25:54
>>606
TryParseは2.0になって利便性のために新たに付け加えられたのであって、
決して「誤り」ではないよ。
0612デフォルトの名無しさん2007/12/11(火) 12:28:32
outで返すとC#でしか使えないことないか？

パラノイア的に統一性に拘らないのであれば（というのは、これに病的に固執する奴っているからね）
値を返さないメソッドに関してだけ例外を返すようにする（返値が必要なのは普通に例外投げる）
というやり方の方が俺は好きだな。
06136112007/12/11(火) 12:28:47
>>606
TryXの使い方のガイドラインあるから読んどけ
http://msdn2.microsoft.com/ja-jp/library/ms229009(VS.80).aspx
0614デフォルトの名無しさん2007/12/11(火) 13:29:25
>>612
outが嫌なら戻り値用の構造体を作ったっていい
>>613
パフォーマンス上の理由なんてのは的外れだ
その例外がめったに起こらなければ起こらないほど
例外のキャッチし忘れは深刻なバグになる
起こるか起こらないか分からないようなエラーが起こるものが
通常のメソッドと見た目全く同じに用意されていて
エラーにそなえてtryで囲めというのは間違い探しをしろといっているようなものだ
単に無駄だ
バグであることが分かりやすくなるように設計するべきだ
0615デフォルトの名無しさん2007/12/11(火) 13:30:22
平日の昼間っから暇なんだなあ
0616デフォルトの名無しさん2007/12/11(火) 13:41:10
なんでここは3行にまとめられない奴ばっかりなんだろ
0617デフォルトの名無しさん2007/12/11(火) 13:57:19
例外のキャッチし忘れはむしろ深刻にはならない。
0618デフォルトの名無しさん2007/12/11(火) 14:09:17
めったにないことだけどある環境では100回に1回ぐらい例外が投げられることがある
catchしてないのにテストをすり抜けてパッケージソフトとして出荷されてしまった
どうなる？
0619デフォルトの名無しさん2007/12/11(火) 14:14:53
例外は絶対投げちゃダメ！とかTryParseは誤り！とか言う事が極端だな
共有すべき普遍的な知識と自分だけの信念は区別しないと
0620デフォルトの名無しさん2007/12/11(火) 14:16:17
そんな事言ってる人居たっけ
0621デフォルトの名無しさん2007/12/11(火) 14:18:28
>>619
TryParseは正しい
正しく呼び出してもエラーが起こりうる場合例外は投げるべきじゃない
とは言った
0622デフォルトの名無しさん2007/12/11(火) 14:27:16
ちなみにTry〜を使うべきだと俺が考えるものには
メソッドが成功するかどうかが自分のプログラムの状態以外の要因で決まるもの(ハードディスクとかNetworkとか)と
それが正しい呼び出しであるかをテストする機能も正しい使い方のうちに含むもの(TryParse)と二通りある
0623デフォルトの名無しさん2007/12/11(火) 14:33:13
ここふらっとスレなんだけど。
0624デフォルトの名無しさん2007/12/11(火) 14:51:59
だからだろ
0625デフォルトの名無しさん2007/12/11(火) 15:12:12
>>618
キャッチし忘れのバグの方がキャッチもしくは例外をかわした場合のバグより
深刻にはならないって言ってるだけだよ。
0626デフォルトの名無しさん2007/12/11(火) 15:17:39
ある環境では100回に一回発生する例外を
常にちゃんと認識しててきっちり対処出来るんなら別だけどな。

あくまでバグがあった場合の話で、
バグがないならその方がいいに決まってる。
0627デフォルトの名無しさん2007/12/11(火) 15:29:08
>>626
しかしある種の例外は確率は低いけど不可避なわけだ
>>622の前者のようなのはそうだ

>>625
間違ってるのにエラーを返さない、例外を投げない
それはただのバグだが防ぐのは難しい
しかし例外のキャッチし忘れは簡単に防げる
防げるものは防いだほうがいいし、それが深刻になる場合だってある
0628デフォルトの名無しさん2007/12/11(火) 16:37:32
http://ufcpp.net/study/csharp/oo_exception.html

例外（exception）とは、本来ならばプログラム中で起こってはいけないことが起こってしまうことをいいます。
堅牢なプログラムを作成するためには、例外が起こったときでもプログラムが異常な動作をしないよう、
しっかりと例外処理（exception handling）を行う必要があります。

0629デフォルトの名無しさん2007/12/11(火) 16:44:57
ここが隔離スレになってるから有効に使ってくれ。
C♯, C＃相談室 Part34
http://pc11.2ch.net/test/read.cgi/tech/1162467959/l50
0630デフォルトの名無しさん2007/12/11(火) 17:04:09
今時戻り値だの構造体だのでエラー情報ずらずら返されたら
どうしようかと思うよ。
0631デフォルトの名無しさん2007/12/11(火) 17:18:14
じゃあメソッドの頭にTryとつけるだけでもいい
エラーが不可避ならばそれを分かりやすく示すべきだ
tryで囲んでないのが一目でバグと分かるように
0632デフォルトの名無しさん2007/12/11(火) 17:25:00
しかし例外の型は何が飛んでくるかわからないからな
バージョンアップで新しい例外が投げられるようになってキャッチできない可能性もあるし
outなり構造体なりで返ってくれば不可避な例外の基本クラスは分かるから
それを投げれば、バグによる例外を含まずにキャッチできる
とにかくcatch{}やcatch(Exception)だけはやってはいけないんだ
0633デフォルトの名無しさん2007/12/11(火) 17:47:00
catch(Exception ex) { ログ保存(ex); throw ex; } は時々やる。
0634デフォルトの名無しさん2007/12/11(火) 17:48:33
だからね、例外が深刻な状況につながることはあまりなくて、
むしろキャッチした上でのバグが深刻な状況につながるんだといってる
0635デフォルトの名無しさん2007/12/11(火) 17:53:23
深刻って何だろう
0636デフォルトの名無しさん2007/12/11(火) 17:58:59
>>633
それやるとデバッガが例外が起きた瞬間でブレイクしてくれないだろ
例外のメッセージの何十倍もその瞬間のブレイクの方が有用だし
0637デフォルトの名無しさん2007/12/11(火) 18:20:55
ケースバイケース
0638デフォルトの名無しさん2007/12/11(火) 18:43:20
>>634
何が言いたいのかよく分からん
それでどうするべきだと言ってるんだ？
0639デフォルトの名無しさん2007/12/11(火) 18:43:43
デバッガの使い方をまず身につけろよ。
最終的にはまず大抵どっかでキャッチするんだから
キャッチしたらアウトなんてのは使い物なならんだろ。

ただ、あえてやってるんじゃないなら
throw e;
はやめとけ。
throw;
でいい。
0640デフォルトの名無しさん2007/12/11(火) 18:45:34
とにかくキャッチすべき、キャッチしないバグは深刻
っていってるみたいだから、
キャッチするバグの方が大抵深刻だよっていってるだけ。
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
そろそろ隔離スレへいってくんない
■ このスレッドは過去ログ倉庫に格納されています