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

■No41320 (simano さん) に返信
> しかし、実際には、「値渡し」「参照渡し」というコーディングする上で
> 頻発する場面で、

そもそも「頻発」するかどうかと問われると、
ほとんどの場合、値渡ししか使わないと思います。参照渡しが必要になるケースは稀かと。
実際、.NET Framework を見ても、"out" や "ref" を伴うメソッドは、そう多くはないですし。


基本前提として
　 値渡し では、メソッド内で仮引数のオブジェクトを差し替えても、実引数(呼び出し元の変数)は『同じオブジェクトのまま』。
　参照渡しでは、メソッド内で仮引数のオブジェクトを差し替えると、実引数(呼び出し元の変数)も指し替わる。
だと思います。



≪参照型を【値渡し】する≫
t = this.textBox1;
ByValMethod(t);
　→ (メソッド内で、Text プロパティの内容が編集される可能性はあるかも知れないが)
　　 メソッド実行後に、『t が別のテキストボックスを指している可能性は無い』。同じまま。

≪参照型を｛参照渡し｝する≫
t = this.textBox1;
ByRefMethod(ref t);
　→ メソッド実行後に、t が別のテキストボックスを指している可能性が高い。
　　(t のインスタンスを差し替えないのであれば、値渡しで充分)

≪値型を【値渡し】する≫
p = this.textBox1.Location;
ByValMethod(p);
　→ 値のコピーを渡しているのだから、『p が別の値になっている可能性は無い』。同じまま。

≪値型を｛参照渡し｝する≫
p = this.textBox1.Location;
ByRefMethod(ref p);
　→ メソッド実行後に、p に別の位置が格納されている可能性が高い。
　　(p の値を入れ替えないのであれば、値渡しで充分)
　→ メソッドによる値の修正を目的とするなら、p = Foo(p); の方が意図が伝わりやすい。

■No41366 (simano さん) に返信
> ですが、「参照渡しを行いたい需要もある」、

引数の型が値型であるか参照型であるかに関わらず、
引数に参照渡しを必要とする場合というのは通常、
No41329 のパターンにほぼ限られるかと思います。

それ以外のパターンだと、P/Invoke の場合ぐらいでしょうか。


> 例えば、サーバと通信して、「実データ」と「結果値」を受ける仕様になっているとします。
> 「結果値」が「クライアントから受けた値が不正です」だった場合の処理を書いてみました。
> (…略…)
> 上記の場合、(…略…)例外のパターンを把握するのも一苦労だと思います。
例外が嫌なら、「他の方法で通知する」か「失敗の理由は通知しない」のいずれかかと。

GetFromServer メソッドの利用側に、どのような記述を行わせるのであれば、
「一苦労しない」方法になると思いますか?

---------------
　// 出力引数
　ResultStatus status;
　MyData result = obj.GetFromServer(0, out status);
　if(status == ResultStatus.InvalidData) {
　　MessageBox.Show("失敗1");
　　return;
　}
---------------
　// 戻り値(値型)での判定
　MyData resultStruct = obj.GetFromServer(0);
　if(resultStruct.HasError) {
　　MessageBox.Show("失敗");
　　return;
　}
---------------
　// 戻り値(参照型)での判定
　MyData resultClass = obj.GetFromServer(0);
　if(resultClass == null ) {
　　MessageBox.Show("失敗");
　　return;
　}
---------------
　// エラープロパティでの判定
　MyData result = obj.GetFromServer(0);
　if(obj.LastDllError != Win32Error.NO_ERROR ) {
　　MessageBox.Show("失敗:" + obj.LastDllError);
　　return;
　}
---------------
　// エラー通知イベントでの捕捉
　obj.OnError += delegate { MessageBox.Show("失敗"); }; // エラー理由はイベント引数で
　MyData result = obj.GetFromServer(0);
---------------
　// 例外処理
　MyData result;
　try {
　　result = obj.GetFromServer(0);
　} catch(……) {
　　if(!Recovery(〜)) throw;
　} catch(……) {
　　MessageBox.Show("失敗");
　　return;
　}
---------------

# 他にも幾つかのパターンが考えられるかと思います。


> 「結果値」が「クライアントから受けた値が不正です」だった場合の処理を書いてみました。
結局、最後まで MyData が return される事が無いので、そもそもこのままだと
コンパイルエラーになってしまうかと思いますが、それはさておき。


>   catch (Exception e)
>   {
>     throw;
>   }
この catch 句は無意味だと思いますが……この場合の try/catch は、
どのような動作を目的として記述されているのでしょうか?


>   MyData data = new MyData();
>   data = Server_DataBytes_Value; // サーバの返した実データを渡す。
この記述からして、Server_DataBytes_Value とは、
MyData 型のフィールド変数のようですね。

この場合、最初に割り当てたインスタンスが意味をなしていません。
単純に「MyData data = Server_DataBytes_Value;」で良いかと。


>   int val = Server_Return_Value; // サーバの返した結果値を渡す。
>   if (val == ILLEGAL_ARG) // 「クライアントから受けた値が不正です」などのエラー値。
>   {
>       throw new MyServerException(val); // 自作の例外クラス
>   }
上記の Server_Return_Value は、int 型のフィールド変数ですかね。
比較対象の ILLEGAL_ARG は…… int 型の定数でしょうか?

ここで、変数名を一旦 val に受け直している意図は分かりませんが
(変数名が分かりにくくなっただけのような…?)、何にせよ、
この『GetFromServer メソッド』というものは、
「サーバーと通信して MyData を返す。返せないときは例外を発生。」
という目的で実装されたメソッドという事になるかと思います。

で、その例外のひとつに、「new MyServerException(ILLEGAL_ARG)」がある、と。


> そこで、「結果値」は、戻り値として返す処理が適切なのかなと思いました。
例外だと把握しきれなくて、ILLEGAL_ARG などのint 型(を戻り値や出力引数)で
返す場合には把握することができる…という事にはならないかと。


> dllだったら例外のパターンを把握するのも一苦労だと思います。
それは例外に限らず、どのような返し方であっても一緒では無いでしょうか。

戻り値にしろ、出力引数にしろ、例外にしろ、それらに変更があったのであれば、
利用側にも修正が必要になるでしょうし、利用側に影響を与えたくないのであれば、
内部実装は変更しても、出力情報に対しては手を加えないようにするべきかと思います。


> 後でいつのまにか例外の種類が変わってたらcatchできません。
「例外の種類を変える」とは、どういう意味でしょうか?

・ILLEGAL_ARG の意味が変わったので、利用側が MyServerException.val を利用できなくなった。
・MyServerException の例外が、サーバーエラー以外に対しても throw されるようになった。
・MyServerException を廃止して、別の例外が throw されるように実装し直した。
・MyServerException だけでなく、他の新たな例外も throw される可能性が出てきた。
・素の MyServerException でなく、その継承クラスを throw させることになった。

コードを投稿する場合は、[投稿モード]を通常モードから図表モードに切り替えてください。
(本文を記述する欄のすぐ上に、投稿モードのラジオボタンがあります)


■No41389 (simano さん) に返信
>>　// エラー通知イベントでの捕捉
>>　obj.OnError += delegate { MessageBox.Show("失敗"); }; // エラー理由はイベント引数で
>>　MyData result = obj.GetFromServer(0);
先のこのパターンは、他と少し毛色が違いますが、非同期的に通知させる事を意図したものです。

BackgroundWorker の RunWorkerCompleted イベントや、
ADODB.Connection の InfoMessage イベントのように、
イベント引数で例外情報を伝えるという状況を想定しています。

# ……もはや参照渡し／値渡しとは関係無い話になってしまいましたが。(^^;


> 魔界の仮面弁士さんの挙げた例のうち、個人的には「出力引数」が一番良いと思いました。
> サーバの返すエラーの種類をアプリケーション側で細かく把握できたほうが、
> 融通が利くためです。
クラスの利用側にエラー内容を細かく把握させること自体は、出力引数以外の手法でも
実装することができると思いますよ(そもそも、例外処理はその一例でしょうし)。

たとえば戻り値で実装するなら、RunWorkerCompletedEventArgs クラスのプロパティのように、
詳細なエラー情報をデータと共に併せ持つといった方法もあるかと思います。
　result = obj.GetFromServer(0);
　if(result.Error == null) {
　　// OK 処理
　　MessageBox.Show(result.Result.ToString());
　} else {
　　// NG 処理
　　if(result.Error is MyServerException) {
　　　Recovery((MyServerException)result.Error);
　　} else {
　　　throw new SimanoAppException("GetFromServer が予期せぬエラーを返しました。", result.Error);
　　}
　}


> 個人的には「出力引数」が一番良いと思いました。
出力引数を使うにしても、その実装パターンは幾つか考えられるかと思います。
　resultStatus = obj.Foo(inputData, out outputData);
　outputData   = obj.Foo(inputData, out resultStatus);
　resultStatus = obj.Foo(ref inputOutputData);

上記はいずれも、「結果データ」と「エラーの有無」を戻り値と引数とで受け取るようになっています。
得られる結果だけみれば、同じ処理目的のために使えますが、それぞれが指し示すメソッドの「意図」は
微妙に異なるため、それぞれの実装を単純に同列に扱うわけにもいきませんよね。


> その際、以下のように、ErrorDefinitionクラスを作成し、エラーの種類を定数で持たせたいと考えました。
const int を切るかわりに、System.Net.WebExceptionStatus や
System.Net.HttpStatusCode などのように、enum にするという手もあります。

この実装方法は、エラーの種類を事前に網羅できる場合に有効かと思います。
たとえば HttpStatusCode は、HTTP/1.1 仕様書に定義されたステータスと等価ですね。
http://www.studyinghttp.net/status_code


> そうすれば、ビルドしたときにライブラリの定数名が変更されれば、
そのライブラリが DLL 参照では無く、プロジェクト参照としてソリューションに組み込まれているならば、
定数名が変更されれば、それを利用する側も機械的にリファクタリングできるかと思います。

ところで private ならばともかく、外部公開されている定数名を後から変える理由は何なのでしょうか?
その理由次第では、何か対応策があるかも知れません。

たとえば当方では、あるメンバにスペルミスが発覚したため、その綴りを変更したい…という状況が
発生した事があったのですが、そのときはスペルを直接修正するのではなく、同じ意味を持つ
正しいスペルの項目を新たに追加し、旧項目に Obsolete 属性を付与させるという手法をとりました。

こうすると、旧項目を使っている場所があれば、リコンパイル時に警告/エラーが通知されますので、
利用側で、完全に置き換え修正が完了した事を確認した上で、その次のバージョンのリリース時に
そのスペルミス項目を削除するようにしました。


> つまり「dllの変更時にthrowされた例外を取りこぼす」等のうっかりミスが減りそうだと考えます。
どの方法にしても、利点もあれば欠点もあると思います。

たとえば、if(ret == ErrorDefinition.SERVER_FILE_NOT_FOUND) の手法だと、
新たな定数コードが増えたときに、呼び出し側の取りこぼしが起こりえそうです。

すべての組みあわせに対して、else if が網羅されていれば、
最後の else にヒットして検出できるかも知れませんけれどね。


> 魔界の仮面弁士さんはどのような例外処理を行っていますか？
少々答えにくい質問ですが… MSDN のガイドラインを参考にしてはいます。
http://msdn.microsoft.com/ja-jp/library/cc433258.aspx
http://msdn.microsoft.com/ja-jp/library/dd296858.aspx
http://msdn.microsoft.com/ja-jp/library/ms229014.aspx


> >「例外の種類を変える」とは、どういう意味でしょうか?
> 以下の意味でした。
> ・MyServerException の例外が、サーバーエラー以外に対しても throw されるようになった。
だとしたら、それは設計ミスだと思いますよ。
例外クラス名と実際の例外の内容が一致しませんし。


> ・MyServerException を廃止して、別の例外が throw されるように実装し直した。
まず、廃止という点について、
　(1)GetFromServer メソッドが MyServerException を throw しなくなった。
　(2)MyServerException クラスに、Obsolete 属性を付与した。
　(3)DLL 内から、MyServerException クラス自体の定義を削除した。
といった 3 つのパターンを想像してみました。

(1) については、呼び出し元の catch 句が埋め殺しになるだけであって、
通常処理系に対しては、影響は少ないような気がします。
(通常処理から外れるがゆえの「例外」なわけですし)

(2) についてはコンパイル段階で発覚しますから、該当箇所の列挙は難しくないでしょう。

(3) に至ってはそもそもコンパイルが通らなくなるので、やはり発見は容易かと。


それから新たな例外の新設という点についてですが、それは確かに
既存の catch(MyServerException ex) では拾われないと思います。しかし
その新設した例外(あるいはその例外の継承元クラス)を catch していない場合、
それはさらにその呼び出し元に伝わっていくわけですよね。ならばテスト段階で
StackTrace を追跡すれば、問題箇所を検出することもできるのでは無いかと。

まぁ、例外を意図的に握りつぶしている箇所の再精査は必要ですが、
そのような再精査は、仕組みが違うにしろ、他の手法(戻り値や出力引数等)でも
同じように全チェックしなければならない事柄でしょうし。