C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

シリアルについて

(過去ログ 6 を表示中)

[トピック内 14 記事 (1 - 14 表示)]　 << 0 >>

■6239 / inTopicNo.1)

　シリアルについて

▼■

□投稿者/ yumi 二等兵(1回)-(2006/09/03(Sun) 13:27:23)

分類:[C#]　

分類:[C#]　

私はＣ＃で例外について勉強していて、
自分で例外クラスを作り、プログラムを書こうと勉強しているのですが、
下記のホームページのシリアル化というのがいまいちよく分かりません。
(例外クラスを継承とかもまだ分かっていませんが・・・どうしてこうも手の込んだ事をしないといけないのか・・・など・・・)
http://www.microsoft.com/japan/msdn/columns/csharp/csharp08162001.aspx
・オブジェクトの状態を永続化または転送できる形式に変換するプロセスのこと
・オブジェクトの内容をバイト列に変換する処理
・オブジェクトの値を保存できるようにすること
・オブジェクトを簡単に転送できる形に変換する処理
・ストリームを渡されたときに、そこにオブジェクトが保持しているデータをすべて書き出すこと
などいろいろとシリアル化を調べると書いてあるのですが、
どれもピンとこない状態です。
私の頭ではどうしてもさっぱりという感じです。
ここのホームページで書いてあるシリアル化というのは、
どういう意味なのでしょうか？
誰か分かり易く教えていただける方がいましたら、よろしくお願いします。

引用返信 編集キー/

■6240 / inTopicNo.2)

　Re[1]: シリアルについて

▲▼■

□投稿者/ επιστημη 曹長(87回)-(2006/09/03(Sun) 15:00:56)

分類:[C#]　

あるオブジェクトを何らかの通信路を通してコッチのアプリからアッチのアプリに送りたい。
となるとオブジェクトをたとえば長い長いバイト列に変換し、そいつを通信路に乗せ、受け取った側ではバイト列からオブジェクトに復元します。

オブジェクト→バイト列: シリアライズ
バイト列→オブジェクト: デシリアライズ

です。

> ここのホームページで書いてあるシリアル化というのは、
> どういう意味なのでしょうか？

コッチのアプリがアッチのアプリにお願いしてなんかの仕事をしてもらう。
そのときアッチのアプリに何らかの異常が発生した。
アッチのアプリはコッチのアプリに例外を投げたい。
けども直接繋がっているわけじゃないので、例外をシリアライズしてコッチに送り返す。

ってことですねぇ。

引用返信 編集キー/

■6241 / inTopicNo.3)

　Re[2]: シリアルについて

▲▼■

□投稿者/ yumi 二等兵(2回)-(2006/09/03(Sun) 15:55:35)

分類:[C#]　

ありがとうございます。
凄く分かり易かったです。
今日は１日中勉強と決めていて、全然進まなかったので、やっと一歩前進です。
アプリからあっちのアプリと云う事は、
そういった事を全然想定していない場合というのは、
自作で例外クラスを作る場合は必要無いと云う事ですか？
よろしくお願いします。

引用返信 編集キー/

■6242 / inTopicNo.4)

　Re[3]: シリアルについて

▲▼■

□投稿者/ επιστημη 曹長(88回)-(2006/09/03(Sun) 16:04:34)

分類:[C#]　

> アプリからあっちのアプリと云う事は、
> そういった事を全然想定していない場合というのは、
> 自作で例外クラスを作る場合は必要無いと云う事ですか？

ごめん、なに言ってんだかわかんない。

引用返信 編集キー/

■6243 / inTopicNo.5)

　Re[4]: シリアルについて

▲▼■

□投稿者/ επιστημη 曹長(89回)-(2006/09/03(Sun) 16:32:03)

分類:[C#]　

ああ、「例外をコッチ⇔アッチに転送する必要がない/想定していない」てことですか。

ならば実装しなくていいでしょう。実装したところで実際に動きゃしないんだから。
「大した手間でもないんだし、やっときゃ後々楽できるわよ」ぐらいに受け止めておけばいいんじゃないかしら。

引用返信 編集キー/

■6244 / inTopicNo.6)

　Re[4]: シリアルについて

▲▼■

□投稿者/ yumi 二等兵(3回)-(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を継承してしまえば問題は無いと思うのですが、
先輩にはオブジェクト指向の考えとしては、一つ親クラスを継承といわれました。
なぜ親クラスを作らないといけないのでしょうか？
よろしくお願いします。
（また質問が分からなかったらスミマセン）

引用返信 編集キー/

■6245 / inTopicNo.7)

　Re[5]: シリアルについて

▲▼■

□投稿者/ επιστημη 曹長(90回)-(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 ) {
　それ以外のほげにまつわる例外はすべてここで面倒見る
}

ってことができるわけよ。

引用返信 編集キー/

■6265 / inTopicNo.8)

　Re[5]: シリアルについて

▲▼■

□投稿者/ Jitta 准尉(101回)-(2006/09/04(Mon) 21:55:44)

分類:[C#]　

　その先輩は、Java な人でしょうか？もしそうなら、
「.NET には、検査例外はなく、例外は総て Java でいう Error だそうです」
と、言ってみましょう。

　Java な人でないなら・・・
　.NET の「例外」は、概ね「これ以上、正常な処理が続けられない」というときに生成します。
それ以外の場合は、まず検証して、正常な処理が続けられる（例えば、ユーザに再入力してもらう）なら、例外を生成せずにすませます。

　どの様な例外を作成しようとされているのかわかりませんが、例えば次のようなケースでは、例外を生成せず、戻り値で判断するように作ります。

＊ユーザが入力した値が、正しいかどうか判断する
＊書き込もうとしているディレクトリに権限がない
　→ IOException をキャッチして、戻り値として通知する（これは、設計に依存するけど）

　例外を生成すると、かなり遅くなります。何らかのチェックですませられるなら、（.NET では）例外を生成せずにすませる方を選びましょう。
# 言語にも依るのかな？

引用返信 編集キー/

■6269 / inTopicNo.9)

　Re[5]: シリアルについて

▲▼■

□投稿者/ yumi 二等兵(4回)-(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(ほげ１Exception ex){
　　throw ex;
　}
　try{
　}catch(ほげ２Exception ex){
　　throw ex;　
　}
}

class B{
　try{
　　//Aのメソッドを呼ぶ
　}catch(ほげ１Exception ex){
　　//エラー処理
　}catch(ほげ２Exception ex){
　　//エラー処理
　}
}
このようにさえすればいいって思ってしまうのです。
>設計の範
と言われてしまえばおしまいなのですが、
ほげ致命的Exceptionを作成するのが、オブジェクト指向的に素晴らしいと分かる、
何かイメージしやすい良い例がありましたら教えてもらえませんか？
あと少しで分かりそうなので、よろしくお願いします。
（質問ばかりでスミマセン。間違った言っていた事を言っていたら指摘お願いします。）

引用返信 編集キー/

■6273 / inTopicNo.10)

　Re[6]: シリアルについて

▲▼■

□投稿者/ επιστημη 曹長(94回)-(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(ほげ１Exception ex){
　//エラー処理
}catch(ほげ２Exception ex){
　//エラー処理
}catch(ほげ３Exception ex){
　//エラー処理
....
}catch(ほげ８３Exception ex) {
　// もぉ勘弁してくださいおうちに帰らせてください
}

その100種類が異常の種別ごとに分類されてたら:

} catch ( ほげ修復不可能Exception criticalhogex ) {
　...ヤバい異常に対処
　ほげ致命的Exceptionも(ほげ修復不可能Exceptionから導出しているので)
　ここでcatchされる
} catch ( ほげ修復可能Exception recoverablehogex ) {
　...マズい異常に対処
} catch ( ほげException hogex ) {
　...残りはテキトーに対処
}

みたいに対処する側が楽できますやろ?
後日throwすべき異常が増えてもcatch側のコード修正が少なくて済みますやん。
"1番と2番と6番と92番が致命的だからぁ…"なんてコード書かんでええわけやし。

要は"まとめ感覚(グループ分け)"なのよ

引用返信 編集キー/

■6275 / inTopicNo.11)

　Re[7]: シリアルについて

▲▼■

□投稿者/ 中博俊神(714回)-(2006/09/05(Tue) 00:36:06)

分類:[C#]　

たぶん
ほげ修復不可能Exception
を捕まえて何をするかがイメージできていないんだとおもわれ。
私も捕まえることはないと思いますが。

設計なんですよね～

そこにいる先輩捕まえて、食い下がってみて論戦してみたらいいんです。
たぶんそういうの好きだろうし。

引用返信 編集キー/

■6276 / inTopicNo.12)

　Re[8]: シリアルについて

▲▼■

□投稿者/ επιστημη 曹長(95回)-(2006/09/05(Tue) 01:55:50)

分類:[C#]　

> そこにいる先輩捕まえて、食い下がってみて論戦してみたらいいんです。
> たぶんそういうの好きだろうし。

うん、確かにその先輩の主張する:

先輩に言われたのが、
まず、例外の親クラスを自分で作成し、
その親クラスを継承して、それぞれ見合った例外クラスを作る

の真意を問いたくもありますねぇ。
'なぜ'そうするのか/'どんなとき'そうしないのか。

引用返信 編集キー/

■6281 / inTopicNo.13)

　Re[9]: シリアルについて

▲▼■

□投稿者/ 中博俊神(716回)-(2006/09/05(Tue) 09:27:35)

分類:[C#]　

先輩が教科書的にやれっていってんだったら、じゃぁなぜ？なぜ？いらないよね？っておいつめて(^^;;

引用返信 編集キー/

■6308 / inTopicNo.14)

　Re[10]: シリアルについて

▲▼■

□投稿者/ Jitta 准尉(102回)-(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するような場面というのがイメージ出来ないのです。
　イメージできなくて正解です。キャッチする必要はありません。
　業務の流れの中で想定される「例外」は、すべてエラー戻り値として設計します。
　ユーザが入力を間違えるかもしれない。これは、想定でき、再入力を促すことで復帰できます。例外として実装せず、エラー戻り値として実装します。
　データベースサーバがダウンしており、アクセスできないかもしれない。これは想定できますが、このエラーをキャッチしたからといって、業務を復帰できません。まず、データベースサーバを起動させ、データの破損がないか調べなければなりません。破損があれば、当然業務を続けることは出来ません。したがって、アクセスできないことがわかった時点では、復帰できるかどうか判断できません。これを例外としてスローし、業務、すなわちアプリケーション自体を停止します。アプリケーションを停止させるので、キャッチする必要はありません。
　しかし、ログをとったり、ユーザに何らかのメッセージを出す必要があるかもしれません。その為には、アプリケーションのエントリポイントなど、かなり上位の箇所でキャッチして、適切に処理します。

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -