C# と VB.NET の質問掲示板
ASP.NET、C++/CLI、Java 何でもどうぞ
掲示板トップ
C# と VB.NET 入門
新規作成
利用方法
ツリー表示
トピック表示
ランキング
記事検索
過去ログ
ログ内検索
キーワードを複数指定する場合は 半角スペース で区切ってください。
検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
[返信]をクリックすると返信ページへ移動します。
キーワード
/
検索条件
/
(AND)
(OR)
検索範囲
/
(現在のログ)
(全過去ログ)
(過去ログ1)
(過去ログ2)
(過去ログ3)
(過去ログ4)
(過去ログ5)
(過去ログ6)
(過去ログ7)
(過去ログ8)
(過去ログ9)
(過去ログ10)
(過去ログ11)
(過去ログ12)
(過去ログ13)
(過去ログ14)
(過去ログ15)
(過去ログ16)
(過去ログ17)
(過去ログ18)
(過去ログ19)
(過去ログ20)
(過去ログ21)
(過去ログ22)
(過去ログ23)
(過去ログ24)
(過去ログ25)
(過去ログ26)
(過去ログ27)
(過去ログ28)
(過去ログ29)
(過去ログ30)
(過去ログ31)
(過去ログ32)
(過去ログ33)
(過去ログ34)
(過去ログ35)
(過去ログ36)
(過去ログ37)
(過去ログ38)
(過去ログ39)
(過去ログ40)
(過去ログ41)
(過去ログ42)
(過去ログ43)
(過去ログ44)
(過去ログ45)
(過去ログ46)
(過去ログ47)
(過去ログ48)
(過去ログ49)
(過去ログ50)
(過去ログ51)
(過去ログ52)
(過去ログ53)
(過去ログ54)
(過去ログ55)
(過去ログ56)
(過去ログ57)
(過去ログ58)
(過去ログ59)
(過去ログ60)
(過去ログ61)
(過去ログ62)
(過去ログ63)
(過去ログ64)
(過去ログ65)
(過去ログ66)
(過去ログ67)
(過去ログ68)
(過去ログ69)
(過去ログ70)
(過去ログ71)
(過去ログ72)
(過去ログ73)
(過去ログ74)
(過去ログ75)
(過去ログ76)
(過去ログ77)
(過去ログ78)
(過去ログ79)
(過去ログ80)
(過去ログ81)
(過去ログ82)
(過去ログ83)
(過去ログ84)
(過去ログ85)
(過去ログ86)
(過去ログ87)
(過去ログ88)
(過去ログ89)
(過去ログ90)
(過去ログ91)
(過去ログ92)
(過去ログ93)
(過去ログ94)
(過去ログ95)
(過去ログ96)
(過去ログ97)
(過去ログ98)
(過去ログ99)
(過去ログ100)
(過去ログ101)
(過去ログ102)
(過去ログ103)
(過去ログ104)
(過去ログ105)
(過去ログ106)
(過去ログ107)
(過去ログ108)
(過去ログ109)
(過去ログ110)
(過去ログ111)
(過去ログ112)
(過去ログ113)
(過去ログ114)
(過去ログ115)
(過去ログ116)
(過去ログ117)
(過去ログ118)
(過去ログ119)
(過去ログ120)
(過去ログ121)
(過去ログ122)
(過去ログ123)
(過去ログ124)
(過去ログ125)
(過去ログ126)
(過去ログ127)
(過去ログ128)
(過去ログ129)
(過去ログ130)
(過去ログ131)
(過去ログ132)
(過去ログ133)
(過去ログ134)
(過去ログ135)
(過去ログ136)
(過去ログ137)
(過去ログ138)
(過去ログ139)
(過去ログ140)
(過去ログ141)
(過去ログ142)
(過去ログ143)
(過去ログ144)
(過去ログ145)
(過去ログ146)
(過去ログ147)
(過去ログ148)
(過去ログ149)
(過去ログ150)
(過去ログ151)
(過去ログ152)
(過去ログ153)
(過去ログ154)
(過去ログ155)
(過去ログ156)
(過去ログ157)
(過去ログ158)
(過去ログ159)
(過去ログ160)
(過去ログ161)
(過去ログ162)
(過去ログ163)
(過去ログ164)
(過去ログ165)
(過去ログ166)
(過去ログ167)
(過去ログ168)
(過去ログ169)
(過去ログ170)
(過去ログ171)
(過去ログ172)
(過去ログ173)
(過去ログ174)
(過去ログ175)
(過去ログ176)
(過去ログ177)
(過去ログ178)
(過去ログ179)
強調表示
/
ON
(自動リンクOFF)
結果表示件数
/
20件
30件
40件
50件
100件
記事No検索
/
ON
大文字と小文字を区別する
No.6239 の関連記事表示
ヒット / 15件
(1-15 を表示)
<<
0
>>
■6308
Re[10]: シリアルについて
□投稿者/ Jitta -
(2006/09/05(Tue) 20:44:09)
分類:[C#]
> ほげ致命的Exceptionを作成するのが、オブジェクト指向的に素晴らしいと分かる、
> 何かイメージしやすい良い例がありましたら教えてもらえませんか?
ここ数年、いろいろなものが「漫画化」していますよね。小説などの「絵」がないものより、それを漫画化した「絵」があるものの方が、売れ行きが良いそうです。
Hoge致命的Exception を作るのも、そういうことです。
「Hoge1Exception」だと、システムにとってクリティカルであることが、その後の処理を読むまでわかりません。しかし、「Hoge致命的Exception」だと、この宣言を見ただけでクリティカルであることがわかります。
で、両方されるということなので、おそらく Java の例外システムを .NET に持ち込もうとされているのだと思います。
繰り返しますが、Java の「検査例外」は、.NET にはありません。.NET の例外は、Java の Error に相当します。
このことをふまえた上で、catch しまくる必要はありません。いくつかの「システム エラー」を、「業務エラー」に読み替える場合のみ、catch します。
> このような感じで、「ほげException」を継承した「ほげ致命的Exception」を
> catchするような場面というのがイメージ出来ないのです。
イメージできなくて正解です。キャッチする必要はありません。
業務の流れの中で想定される「例外」は、すべてエラー戻り値として設計します。
ユーザが入力を間違えるかもしれない。これは、想定でき、再入力を促すことで復帰できます。例外として実装せず、エラー戻り値として実装します。
データベース サーバがダウンしており、アクセスできないかもしれない。これは想定できますが、このエラーをキャッチしたからといって、業務を復帰できません。まず、データベース サーバを起動させ、データの破損がないか調べなければなりません。破損があれば、当然業務を続けることは出来ません。したがって、アクセスできないことがわかった時点では、復帰できるかどうか判断できません。これを例外としてスローし、業務、すなわちアプリケーション自体を停止します。アプリケーションを停止させるので、キャッチする必要はありません。
しかし、ログをとったり、ユーザに何らかのメッセージを出す必要があるかもしれません。その為には、アプリケーションのエントリ ポイントなど、かなり上位の箇所でキャッチして、適切に処理します。
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6281
Re[9]: シリアルについて
□投稿者/ 中博俊
@
-
(2006/09/05(Tue) 09:27:35)
>
分類:[C#]
先輩が教科書的にやれっていってんだったら、じゃぁなぜ?なぜ?いらないよね?っておいつめて(^^;;
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6276
Re[8]: シリアルについて
□投稿者/ επιστημη -
(2006/09/05(Tue) 01:55:50)
>
分類:[C#]
> そこにいる先輩捕まえて、食い下がってみて論戦してみたらいいんです。
> たぶんそういうの好きだろうし。
うん、確かにその先輩の主張する:
先輩に言われたのが、
まず、例外の親クラスを自分で作成し、
その親クラスを継承して、それぞれ見合った例外クラスを作る
の真意を問いたくもありますねぇ。
'なぜ'そうするのか/'どんなとき'そうしないのか。
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6275
Re[7]: シリアルについて
□投稿者/ 中博俊
@
-
(2006/09/05(Tue) 00:36:06)
>
分類:[C#]
たぶん
ほげ修復不可能Exception
を捕まえて何をするかがイメージできていないんだとおもわれ。
私も捕まえることはないと思いますが。
設計なんですよね〜
そこにいる先輩捕まえて、食い下がってみて論戦してみたらいいんです。
たぶんそういうの好きだろうし。
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6273
Re[6]: シリアルについて
□投稿者/ επιστημη -
(2006/09/05(Tue) 00:17:29)
>
分類:[C#]
> ほげ致命的Exceptionを作成するのが、オブジェクト指向的に素晴らしいと分かる、
> 何かイメージしやすい良い例がありましたら教えてもらえませんか?
例外ちゅーのはですね。
- 呼ばれた側は異常を検出できるけどその対処法をしらない。
- 呼んだ側は異常に対処できるけどその検出はできない。
ってシチュエーションのとき、呼ばれた側が呼んだ側に向かってエレガントに異常を知らせるからくりです。
呼ばれた側(例外をthrowする側)はその受取人がその異常にどう対処するか知りません。
ならばthrowする側はcatch側での対処が楽なようにthrowするのが親切ってもの。
呼ばれた側で検出される異常が100種類あったとしましょう。
このときたった一つの例外をthrowし、catch側では例外に納められたエラーコードで対処を振り分けるとなると:
} catch ( ほげException hogex ) {
switch ( hogex.code ) {
case 0: ...
case 1: ...
やってらんねー!!
}
あるいはズラリとExceptionを定義して:
}catch(ほげ1Exception ex){
//エラー処理
}catch(ほげ2Exception ex){
//エラー処理
}catch(ほげ3Exception ex){
//エラー処理
....
}catch(ほげ83Exception ex) {
// もぉ勘弁してくださいおうちに帰らせてください
}
その100種類が異常の種別ごとに分類されてたら:
} catch ( ほげ修復不可能Exception criticalhogex ) {
...ヤバい異常に対処
ほげ致命的Exceptionも(ほげ修復不可能Exceptionから導出しているので)
ここでcatchされる
} catch ( ほげ修復可能Exception recoverablehogex ) {
...マズい異常に対処
} catch ( ほげException hogex ) {
...残りはテキトーに対処
}
みたいに対処する側が楽できますやろ?
後日throwすべき異常が増えてもcatch側のコード修正が少なくて済みますやん。
"1番と2番と6番と92番が致命的だからぁ…"なんてコード書かんでええわけやし。
要は"まとめ感覚(グループ分け)"なのよ
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6269
Re[5]: シリアルについて
□投稿者/ yumi -
(2006/09/04(Mon) 23:15:44)
分類:[C#]
2006/09/04(Mon) 23:17:35 編集(投稿者)
えーっと、何て読むのかな・・・
επιστημηさん、そして、Jittaさんありがとうございます。
>例外を生成すると、かなり遅くなります
というのは始めて知り、とても勉強になりました。
ちなみに先輩はどちらの言語もやります。
επιστημηさんに質問したいのですが、
どうしても分からない状態です(スミマセン)。
try {
...
} catch ( ほげ致命的Exception criticalhogex ) {
// ほげ致命的Exception は ほげException から導出
ほげがかなりヤバいときの処理
} catch ( ほげException hogex ) {
それ以外のほげにまつわる例外はすべてここで面倒見る
}
↑のソースでメインで全ての例外を受け取る事を考えた場合は、
} catch ( ほげ致命的Exception criticalhogex ) {
} catch ( ほげException hogex ) {
} catch ( Exception ex) {
}
というようにExceptionを付ける事になるのでしょうか?
(設計の範疇です!と言われてしまうと何も聞けないですが・・・)
話は変わり、親独自エラークラスを作り、それを継承していろいろとエラークラスを作る話なのですが、
先輩に言われた事は、ソースの拡張をしやすいから、このような事をすると言っていました。
しかし、自分としては
} catch ( ほげ致命的Exception criticalhogex ) {
} catch ( ほげException hogex ) {
このような感じで、「ほげException」を継承した「ほげ致命的Exception」を
catchするような場面というのがイメージ出来ないのです。
こうやってソースを組めば、処理が出来るというのは分かるのですが、
このソースの良さが分からないのです。
どうしても、
>あなたが投げたい例外が唯一ひとつなら直接ApplicationExceptionから導出すりゃええ
と言うように、
class A{
try{
}catch(ほげ1Exception ex){
throw ex;
}
try{
}catch(ほげ2Exception ex){
throw ex;
}
}
class B{
try{
//Aのメソッドを呼ぶ
}catch(ほげ1Exception ex){
//エラー処理
}catch(ほげ2Exception ex){
//エラー処理
}
}
このようにさえすればいいって思ってしまうのです。
>設計の範
と言われてしまえばおしまいなのですが、
ほげ致命的Exceptionを作成するのが、オブジェクト指向的に素晴らしいと分かる、
何かイメージしやすい良い例がありましたら教えてもらえませんか?
あと少しで分かりそうなので、よろしくお願いします。
(質問ばかりでスミマセン。間違った言っていた事を言っていたら指摘お願いします。)
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6265
Re[5]: シリアルについて
□投稿者/ Jitta -
(2006/09/04(Mon) 21:55:44)
分類:[C#]
その先輩は、Java な人でしょうか?もしそうなら、
「.NET には、検査例外はなく、例外は総て Java でいう Error だそうです」
と、言ってみましょう。
Java な人でないなら・・・
.NET の「例外」は、概ね「これ以上、正常な処理が続けられない」というときに生成します。
それ以外の場合は、まず検証して、正常な処理が続けられる(例えば、ユーザに再入力してもらう)なら、例外を生成せずにすませます。
どの様な例外を作成しようとされているのかわかりませんが、例えば次のようなケースでは、例外を生成せず、戻り値で判断するように作ります。
* ユーザが入力した値が、正しいかどうか判断する
* 書き込もうとしているディレクトリに権限がない
→ IOException をキャッチして、戻り値として通知する(これは、設計に依存するけど)
例外を生成すると、かなり遅くなります。何らかのチェックですませられるなら、(.NET では)例外を生成せずにすませる方を選びましょう。
# 言語にも依るのかな?
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6245
Re[5]: シリアルについて
□投稿者/ επιστημη -
(2006/09/03(Sun) 17:05:50)
>
分類:[C#]
■
No6244
に返信(yumiさんの記事)
> 先輩に言われたのが、
> まず、例外の親クラスを自分で作成し、
> その親クラスを継承して、それぞれ見合った例外クラスを作ると言われました。
> そして調べていくと、
> ここのホームページの感じで、親クラスを作り、例えば、エラー番号が欲しい例外クラスが必要なら、
> 親クラスを継承して、その継承した例外クラスに、エラー番号のgetter,setterを作成する。
> このような形にしていくのかな?と思っているのですが、
> なぜこの親クラスが必要になるのかが分からないのです。
そこはもう設計の範疇になります。
あなたが投げたい例外が唯一ひとつなら直接ApplicationExceptionから導出すりゃええ。
けどもクラス'ほげ'がいくつもの例外を投げることになるなら
class ほげException : ApplicationException { ... }
しておいて数種の例外を ほげException から導出しておけば、
try {
...
} catch ( ほげ致命的Exception criticalhogex ) {
// ほげ致命的Exception は ほげException から導出
ほげがかなりヤバいときの処理
} catch ( ほげException hogex ) {
それ以外のほげにまつわる例外はすべてここで面倒見る
}
ってことができるわけよ。
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6244
Re[4]: シリアルについて
□投稿者/ yumi -
(2006/09/03(Sun) 16:32:08)
分類:[C#]
あるコンピュータから別のコンピュータに例外を渡すという事を想定していない場合は、
例外のシリアル化はあんまり考えなくても良いという事になるのですか?
という質問でした。
(↑これでいけますでしょうか?)
というよりか、よくホームページ(
http://www.microsoft.com/japan/msdn/columns/csharp/csharp08162001.aspx
)を見ると、例外のシリアル化の少し上らへんに、
「例外クラスを使い始めるには、これで十分でしょう。」
と書いていました。
スミマセン。
しかし、記事を読んでいくとやはり例外クラスというのが良く分からないです。
先輩に言われたのが、
まず、例外の親クラスを自分で作成し、
その親クラスを継承して、それぞれ見合った例外クラスを作ると言われました。
そして調べていくと、
ここのホームページの感じで、親クラスを作り、例えば、エラー番号が欲しい例外クラスが必要なら、
親クラスを継承して、その継承した例外クラスに、エラー番号のgetter,setterを作成する。
このような形にしていくのかな?と思っているのですが、
なぜこの親クラスが必要になるのかが分からないのです。
自分の作りたいエラー番号を保持した例外クラスに、
public class ErrNoException: ApplicationException
というような形でいきなりApplicationExceptionを継承してしまえば問題は無いと思うのですが、
先輩にはオブジェクト指向の考えとしては、一つ親クラスを継承といわれました。
なぜ親クラスを作らないといけないのでしょうか?
よろしくお願いします。
(また質問が分からなかったらスミマセン)
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6243
Re[4]: シリアルについて
□投稿者/ επιστημη -
(2006/09/03(Sun) 16:32:03)
>
分類:[C#]
ああ、「例外をコッチ⇔アッチに転送する必要がない/想定していない」てことですか。
ならば実装しなくていいでしょう。実装したところで実際に動きゃしないんだから。
「大した手間でもないんだし、やっときゃ後々楽できるわよ」ぐらいに受け止めておけばいいんじゃないかしら。
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6242
Re[3]: シリアルについて
□投稿者/ επιστημη -
(2006/09/03(Sun) 16:04:34)
>
分類:[C#]
> アプリからあっちのアプリと云う事は、
> そういった事を全然想定していない場合というのは、
> 自作で例外クラスを作る場合は必要無いと云う事ですか?
ごめん、なに言ってんだかわかんない。
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6241
Re[2]: シリアルについて
□投稿者/ yumi -
(2006/09/03(Sun) 15:55:35)
分類:[C#]
ありがとうございます。
凄く分かり易かったです。
今日は1日中勉強と決めていて、全然進まなかったので、やっと一歩前進です。
アプリからあっちのアプリと云う事は、
そういった事を全然想定していない場合というのは、
自作で例外クラスを作る場合は必要無いと云う事ですか?
よろしくお願いします。
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6240
Re[1]: シリアルについて
□投稿者/ επιστημη -
(2006/09/03(Sun) 15:00:56)
>
分類:[C#]
あるオブジェクトを何らかの通信路を通してコッチのアプリからアッチのアプリに送りたい。
となるとオブジェクトをたとえば長い長いバイト列に変換し、そいつを通信路に乗せ、受け取った側ではバイト列からオブジェクトに復元します。
オブジェクト→バイト列: シリアライズ
バイト列→オブジェクト: デシリアライズ
です。
> ここのホームページで書いてあるシリアル化というのは、
> どういう意味なのでしょうか?
コッチのアプリがアッチのアプリにお願いしてなんかの仕事をしてもらう。
そのときアッチのアプリに何らかの異常が発生した。
アッチのアプリはコッチのアプリに例外を投げたい。
けども直接繋がっているわけじゃないので、例外をシリアライズしてコッチに送り返す。
ってことですねぇ。
記事No.6239 のレス /0過去ログ6より /
関連記事表示
削除チェック/
■6239
シリアルについて
□投稿者/ yumi -
(2006/09/03(Sun) 13:27:23)
分類:[C#]
分類:[C#]
私はC#で例外について勉強していて、
自分で例外クラスを作り、プログラムを書こうと勉強しているのですが、
下記のホームページのシリアル化というのがいまいちよく分かりません。
(例外クラスを継承とかもまだ分かっていませんが・・・どうしてこうも手の込んだ事をしないといけないのか・・・など・・・)
http://www.microsoft.com/japan/msdn/columns/csharp/csharp08162001.aspx
・オブジェクトの状態を永続化または転送できる形式に変換するプロセスのこと
・オブジェクトの内容をバイト列に変換する処理
・オブジェクトの値を保存できるようにすること
・オブジェクトを簡単に転送できる形に変換する処理
・ストリームを渡されたときに、そこにオブジェクトが保持しているデータをすべて書き出すこと
などいろいろとシリアル化を調べると書いてあるのですが、
どれもピンとこない状態です。
私の頭ではどうしてもさっぱりという感じです。
ここのホームページで書いてあるシリアル化というのは、
どういう意味なのでしょうか?
誰か分かり易く教えていただける方がいましたら、よろしくお願いします。
親記事 /0過去ログ6より /
関連記事表示
削除チェック/
■6239
Re[11]: 時計回り、反時計回り判定
□投稿者/ y4yama -
(2007/08/06(Mon) 16:40:28)
■
No6236
(Zee さん) に返信
測量の常識!なんですね。外積=面積ですもんねぇ〜
この計算は、閉じた図形の外に原点がある場合にも
一般化されたものなのでしょうか?
閉じた図形の中に原点があるのなら、直感的によ〜く理解できるんですが・・・
記事No.6130 のレス /過去ログ18より /
関連記事表示
削除チェック/
<<
0
>>
パスワード/
-
Child Tree
-