- PR -

C# 戻り値の型を動的に変更することは可能ですか？

投稿者

投稿内容

未記入: ぬし; 会議室デビュー日: 2004/09/17; 投稿数: 667

投稿日時: 2005-05-03 10:21

補足ありがとうございます。

引用:
デザインガイド違反を承知でJavaっぽくやっちゃってます^^;

デザインガイド ではなくデザインルール なのだそうです。やはり、.NET では例外の使用は禁じ手なんだと思います。仮に例外を使うとしても、すべて自分の責任範囲で、つまり自分で投げて自分でキャッチしなければいけないのでしょう。Atsushi.Eno さんが当初から言われていた「呼び出し元が限られていて十分に制御出来る場合にしか～」というのも今では納得がいきます。

これは自分で例外をキャッチすることができない汎用ライブラリの設計には例外を使用することができないことを意味しますね。もし、Jitta さん, k-nak さん, 未記入などのように (.NET のデザインルールに照らして) 間違った例外の使い方をする人が作成したライブラリを使うと、アプリケーションが落ちます。みんな「例外をキャッチすべきではない」と考えているので、ライブラリ作成者が安易な気持ちで投げた IOException がアプリケーションを落としてしまうことになります。例外はとても危険な手法です。例外を使うくらいなら object 型を使ったほうがマシなのです。Jitta さんの提示してくれた例外を使ったコードは確かに可読性が高くシンプルですが、アプリケーションが落ちてしまうのでは意味がありませんよね。

.NET には結構、興味持っていたんだけどなあ。以前も Jitta さんにテキスト入力欄の幅に入力テキストを合わせこんで長体表示するサンプルコードとか見せてもらって感銘を受けたものだけど。やはり、私は Java から離れることはできそうもありません。Longhorn でランタイムの遅さが克服されたら移行してもいいかなと思っていたんだけど、そう簡単にはいかないようですね。

一郎: ぬし; 会議室デビュー日: 2002/10/11; 投稿数: 1081

投稿日時: 2005-05-03 11:27

引用:
k-nakさんの書き込み (2005-05-03 04:46) より: DotNETのデザインガイドに厳密に従うと、エラー応答処理があちこちに分散するか、もしくはあちこちのメソッドでエラー情報を返すoutパラメータだらけになるかと思うのですが……

そうですか？
outでエラー情報を返す作りにしているということは、そのエラーが出ることが"想定の範囲内"(流行語か)ということですよね。
ですので、事前にその作業を行えるかチェックをするようにしておけば、作業を行うメソッド等にはoutパラメータは必要ないのではないでしょうか。

ファイルへのアクセスを例にとれば、もし通常の運用ではファイルにアクセスできないことは考えられないという場合は、ファイルアクセスのメソッド内でファイルにアクセスできなかった場合は例外を外に投げるのをためらうべきではありません。
なぜなら"ファイルにアクセスできない"というのは想定の範囲外だからです。
逆に通常の運用でファイルにアクセスできないこともありうるという場合も、ファイルアクセスのメソッド内でファイルにアクセスできなかった場合は例外を外に投げるべきです。
想定されている"ファイルにアクセスできない"という状態かどうかのチェックとファイルへのアクセスを同じメソッドで実装するべきではないからです。つまりファイルアクセスのメソッド自体は失敗することは想定していないということ。

想定の範囲内とか範囲外とか書きましたけど、極端に言えば「try-catchを書いているということは、それを想定しているということじゃないか」ということになるかもしれませんが、if文のような条件分岐のように使わないという意識でいいんじゃないですかね。

nanbu: 大ベテラン; 会議室デビュー日: 2004/08/19; 投稿数: 178

投稿日時: 2005-05-03 12:24

引用:
デザインガイドではなくデザインルールなのだそうです。やはり、.NET では例外の使用は禁じ手なんだと思います。仮に例外を使うとしても、すべて自分の責任範囲で、つまり自分で投げて自分でキャッチしなければいけないのでしょう。

引用:

これは自分で例外をキャッチすることができない汎用ライブラリの設計には例外を使用することができないことを意味しますね。もし、Jitta さん, k-nak さん, 未記入などのように (.NET のデザインルールに照らして) 間違った例外の使い方をする人が作成したライブラリを使うと、アプリケーションが落ちます。みんな「例外をキャッチすべきではない」と考えているので、ライブラリ作成者が安易な気持ちで投げた IOException がアプリケーションを落としてしまうことになります。

南部です。

デザインルールと記述したのは私なので、、、
引用部内の次のものは間違いです。
１．.NET では例外の使用は禁じ手
２．自分で投げて自分でキャッチしなければいけない
３．汎用ライブラリの設計には例外を使用することができない
４．これらを論拠に導いたもの

.NETとJavaでは例外の取り扱いが違うとはいっても、業務エラーか例外かをハンドリングする点でそんなに変わりません。（例外はアプリケーションエラーもしくはシステムエラーを指す）

Javaでは、throws IOException のようにコンパイラレベルでハンドリングを強制できるだけです。

例えば、ログインメソッド（ビジネスメソッド）の場合
Javaでは、
public void login(引数) throws LoginException;
のようなインターフェースになるに対し、
.NETでは、
public bool Login(引数）;
のようなインターフェースになります。

Javaでは、SQLExceptionがloginメソッド内でキャッチされ、
業務エラーであれば、LoginExceptionを生成しスローします。
（これは、呼び出し元に業務エラーがあったことの報告に過ぎません）
そうでない場合、接続できない場合などのシステムエラーだった
場合、LoginException以外の検査例外はスローできないので、
RuntimeExceptionに変換しスローし、ビジネスフローを出ます。
（ビジネスフローでは、キャッチすべきではありません）

一方、.NETでは、SQLExceptionをLoginメソッド内でキャッチし、
業務エラーであればfalseを返します。
そうでない場合、接続できない場合などのシステムエラーだった
場合、そのまま例外を投げます。
（ビジネスフローでは、キャッチすべきではありません）

#どっちも、取り扱いが違うだけでほとんど同じです

そして、Loginメソッドは汎用ライブラリには含まれないでしょう。
だって、ビジネスメソッドですから。

これがデザインルールです。
なので、

引用:
Jitta さん, k-nak さん, 未記入などのように (.NET のデザインルールに照らして) 間違った例外の使い方をする人が作成したライブラリを使うと

間違っていません。（私が間違っていなければですが）

taka: 会議室デビュー日: 2005/05/03; 投稿数: 14

投稿日時: 2005-05-03 13:37

引用:
一郎さんの書き込み (2005-05-03 11:27) より: 事前にその作業を行えるかチェックをするようにしておけば、作業を行うメソッド等にはoutパラメータは必要ないのではないでしょうか。

そうですね、ロックして、チェックをして、その戻り値をチェックして、処理を行って、ロックを解除して。
そうすればいいのはわかります。
しかし、ドキュメントに、「メソッドBを呼ぶ前には必ずメソッドAを呼んで返値をチェックしてください」と書くことを非常にあほらしく思う私もいるわけです。
なんだかCっぽいな…と。
そういう言語なんだから仕方ないんですけどね。

未記入: ぬし; 会議室デビュー日: 2004/09/17; 投稿数: 667

投稿日時: 2005-05-03 14:52

引用:
例えば、ログインメソッド（ビジネスメソッド）の場合 Javaでは、public void login(引数) throws LoginException; のようなインターフェースになる

普通は Java でも boolean login(...) にすると思います。私なら次のようにします。

コード:


public boolean login(String username, String password) throws LoginException {
    try {
        ... 認証処理 ...
    } catch(Exception e) {
        throw new LoginException(...); // e を cause にしないほうがいい。
    }
}

与えられたユーザー名とパスワードが正しければ true を返します。与えられたユーザー名とパスワードが正しくなければ false を返します。正しいかどうか分からない場合は例外を投げます。正しいかどうか分からないというのは、たとえば、認証に使用しているユーザーエントリファイルやデータベースが破損か何かで読み取れないような状況です。この場合、正規ユーザーもログインできませんので、true を返すのも false を返すのもふさわしくないわけです。それと、login メソッド内全体を try-catch で囲んで LoginException(RuntimeExceptionの自作サブクラス)でラップしているのは login というメソッドの性質上デリケートそうだったからです。素の FileNotFoundException や SQLException がそのまま上位に伝播するのを見逃すと、ログイン機構の仕組みを外部に露呈することになる可能性があるからです。

nak2k: ベテラン; 会議室デビュー日: 2003/07/17; 投稿数: 86

投稿日時: 2005-05-03 16:34

南部さんの例は、以下のような仕様変更が入ったときにJavaのアプローチのアドバンテージがはっきりしますね。

仕様変更：
ログインに失敗したときは「IDまたはパスワードが違います」、「業務時間外です」などの失敗理由も通知するようにして欲しい。

私があえてDotNETでJavaっぽいアプローチを行う理由の一つです。（Javaと違ってコンパイラのサポートが得られない分、気をつけてコーディングする必要はありますが）

かつのり: ぬし; 会議室デビュー日: 2004/03/18; 投稿数: 2015; お住まい・勤務地: 札幌

投稿日時: 2005-05-04 01:20

.NETは「何となく」というレベルでしか知識がなかったので、
非常に勉強になりました。Javaと比べ例外の概念が違うのですね。

Jitta: ぬし; 会議室デビュー日: 2002/07/05; 投稿数: 6267; お住まい・勤務地: 兵庫県・海手

投稿日時: 2005-05-04 07:05

それじゃぁ、.NET Frameworkのデザインルールに従うと、こんな感じ？

コード:


// 呼び出し

int ret;

if (!isMyFunctionOverflow(value)) {

    // 正常処理

    ret = myFunction(value);

} else {

    // 異常処理

}



// myFunction 

int myFunction(int value) {

    return value * 10000;

}



bool isMyFunctionOverflow(int value) {

    if (value > ???? || value < ????) {

        return true;

    } else {

        return false;

    }

}

・・・やだ

ちなみに、Javaの経験はほとんど無い。

[ メッセージ編集済み編集者: Jitta 編集日時 2005-05-04 07:06 ]

[ メッセージ編集済み編集者: Jitta 編集日時 2005-05-04 07:06 ]

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

＠IT SpecialPR

C# 戻り値の型を動的に変更することは可能ですか？

スキルアップ／キャリアアップ（JOB@IT）