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

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

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

Re[4]: メソッドの例外処理の取得方法に関して


(過去ログ 43 を表示中)

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

■23050 / inTopicNo.1)  メソッドの例外処理の取得方法に関して
  
□投稿者/ レン (1回)-(2008/08/07(Thu) 17:56:27)

分類:[.NET 全般] 

VB2005で開発しています。

今までVB6.0で開発しておりまして、
このときは例外処理の結果などをメソッドの戻り値として返していました。

例えばデータベースクラスがあるとしまして、
SELECT文を実行するクラスを使用すると
1:成功、2:失敗
などとエナムを使って、戻り値で返していました。
失敗はErrorHandlerを使って、例外処理が発生したらすべて
失敗としていました。

VB2005ではTry Catchが使えるので、
この機能をうまく使いたいと思っております。

そこで私は、上記のSELECT文を実行するメソッドに
例外をCatchするような処理を書かずに、
呼び出す側でメソッドの実行をTry Catchで例外を取得しようかと考えました。
毎回戻り値として用意するのが不便であると考えたためです。
必要であれば、当メソッドでは〜〜Exceptionと、××Exceptionが発生しますと
コメントに書いておき、使用する側で例外を取得させようかと思っています。

Try Catchで例外を取得する場合は、
このような記述で問題ないのでしょうか?

皆様であれば、このような場合にどのようなコーディングルールを決めて
コーディングしますか?
ぜひアドバイスを頂きたいです。
よろしくお願い致します。

引用返信 編集キー/
■23062 / inTopicNo.2)  Re[1]: メソッドの例外処理の取得方法に関して
□投稿者/ まどか (574回)-(2008/08/07(Thu) 20:43:27)
No23050 (レン さん) に返信
> 今までVB6.0で開発しておりまして、

まず、オブジェクト指向であれば設計の視点を変える必要があります。
利用する側を起点とせず、末端のクラスから設計していきます。

> 例外をCatchするような処理を書かずに、
> 呼び出す側でメソッドの実行をTry Catchで例外を取得しようかと考えました。

Tryで囲む囲まないはルールの問題ではありません。
そのメソッドなりの仕様として「例外を判断、キャッチする必要がある」からそうするのです。
クラス設計は、自身の外のことを一切考えず、すべて「私は〜である」を定義することです。

> 毎回戻り値として用意するのが不便であると考えたためです。

同様に不便とかそういう理由は成り立ちません。

たとえば、FileNotFoundというEnum定数が返る可能性があるメソッドの場合、当然呼び出し側はそれを判断するIf文を記述するでしょう。
その場合、呼び出し側には内部でFileNotFoundExceptionが発生しているということとその例外型に対する意識はありませんし、その必要もありません。
逆に例外は発生する仕様であれば、呼び出し側はTryを記述するかもしれません。
つまり、返値なのか例外なのかはそのメソッドの仕様なのです。
そして呼び出し側はそれに従うだけです。

当然システム全体の観点で作り方みたいなことはあります。
極端な話、全部関数にしてすべての例外をエラーという返値にしようとか、すべてのプロシージャは一番外をTryで囲むことというルール、
なんてのもあります。
しかし、そのシステムの性質によるところが大きく、逆にマッチする場合は稀です。
一般的に予期できない例外は放置し(何もしない)、仕様上予期できる例外のみを意識します。

> 必要であれば、当メソッドでは〜〜Exceptionと、××Exceptionが発生しますと
> コメントに書いておき、使用する側で例外を取得させようかと思っています。

ということで、コメントではなく仕様として明記することになります。

> Try Catchで例外を取得する場合は、
> このような記述で問題ないのでしょうか?

この「記述」というのが、コードなのかドキュメントなのかが読み取れませんでした。
引用返信 編集キー/
■23063 / inTopicNo.3)  Re[1]: メソッドの例外処理の取得方法に関して
□投稿者/ Jitta on the way (151回)-(2008/08/07(Thu) 21:13:55)
No23050 (レン さん) に返信

受ける必要がある例外のみ受けて、その他は無視。
業務上、頻繁に発生することが想定されるもののみ例外とする。
あるいは、その状態から復帰するのが困難な状況でのみ、例外とする。
例外の Message プロパティは、エンド ユーザーに見せない。自分で例外を設計する場合は、誰が見る例外かを十分に検討する。エンド ユーザーが見る例外なら、そういった例外だけを扱うクラスをつくり、それを継承したクラスを設計する。
引用返信 編集キー/
■23082 / inTopicNo.4)  Re[2]: メソッドの例外処理の取得方法に関して
□投稿者/ レン (2回)-(2008/08/08(Fri) 10:46:45)
ご回答ありがとうございます。

> たとえば、FileNotFoundというEnum定数が返る可能性があるメソッドの場合、当然呼び出し側はそれを判断するIf文を記述するでしょう。
> その場合、呼び出し側には内部でFileNotFoundExceptionが発生しているということとその例外型に対する意識はありませんし、その必要もありません。
> 逆に例外は発生する仕様であれば、呼び出し側はTryを記述するかもしれません。
> つまり、返値なのか例外なのかはそのメソッドの仕様なのです。
> そして呼び出し側はそれに従うだけです。

戻り値として、エラーを返すという仕様は決して間違いではないと受け取ってよろしいでしょうか?
現在は、そのメソッドの仕様として、必要なエナム値を作成していますが、
それは末端クラスがどういう機能にしたいかということであり、
使用する側は、それに従うということですね。

> この「記述」というのが、コードなのかドキュメントなのかが読み取れませんでした。

プログラムでは例外処理を記載せずに、
プログラムのコメントに、〜〜Exceptionが発生しますよ。
と書くことを指していました。


説明が足りませんでしたが、
現在の私の開発手法は、推奨されるような、オブジェクト指向開発となっているのか
不安になり質問させて頂いた次第です。

とても参考になりました。
ありがとうございます。

引用返信 編集キー/
■23084 / inTopicNo.5)  Re[2]: メソッドの例外処理の取得方法に関して
□投稿者/ レン (3回)-(2008/08/08(Fri) 10:49:57)
> 受ける必要がある例外のみ受けて、その他は無視。
> 業務上、頻繁に発生することが想定されるもののみ例外とする。
> あるいは、その状態から復帰するのが困難な状況でのみ、例外とする。
> 例外の Message プロパティは、エンド ユーザーに見せない。自分で例外を設計する場合は、誰が見る例外かを十分に検討する。エンド ユーザーが見る例外なら、そういった例外だけを扱うクラスをつくり、それを継承したクラスを設計する。

例外はすべてキャッチするのではなく、
必要なものだけをキャッチすれば良いということですね。
勉強になりました。

また例外クラスを作成して、
メソッドでは例外を発生させて、使用する側ではそれをキャッチしても良いという
ことですよね?

勉強になりました。

引用返信 編集キー/
■23182 / inTopicNo.6)  Re[3]: メソッドの例外処理の取得方法に関して
□投稿者/ Jitta (507回)-(2008/08/10(Sun) 22:03:37)
Jitta さんの Web サイト
No23084 (レン さん) に返信
> また例外クラスを作成して、
> メソッドでは例外を発生させて、使用する側ではそれをキャッチしても良いという
> ことですよね?

 ああ、ごめん。
 原則として、Exception.Message を、エンド ユーザに見せてはいけません。
これは、開発者用にデザインされているべきです。
しかし、時と場合によっては、エンド ユーザに見せたい場合があります。
この、「見せる」「見せない」の区別を、例外クラスによって行いましょう。

 .NET Framwork 1.x の時は、ApplicationException から派生することが
推奨されていましたが、Base Class Library にその推奨にあわないクラスがあることから、
2.0 からはその推奨が無くなっています。
しかし、上記の理由で、「エンド ユーザに見せても良い例外」を、
ひとつのクラスから派生することを勧めます。

pubic class MyExceptionBase : Exception
{
    // 開発者向けメッセージはこちらへ
    public string Message4dev {
        get;
        set;
    }
    public override string ToString(void) {
        適宜
    }
}
↑
このクラスから派生したクラスを用いれば、

try {
    何かの処理
} catch (MyExceptionBase e) {
    エンド ユーザにそのまま見せても良いメッセージ
} catch (Exception e) {
    エンド ユーザには「ご迷惑をおかけしております」だけ見せ、
    メッセージ内容はログに落とす。
}
↑
のような使い分けができる。

引用返信 編集キー/
■23187 / inTopicNo.7)  Re[4]: メソッドの例外処理の取得方法に関して
□投稿者/ やじゅ (526回)-(2008/08/10(Sun) 23:51:34)
やじゅ さんの Web サイト
> ■No23084 (レン さん) に返信

NAL-6295さんのが参考になるかな
むやみにキャッチしないでね。ゴールキーパー以外はハンドで反則ですよ。
http://d.hatena.ne.jp/NAL-6295/20050909/p1

引用返信 編集キー/
■23252 / inTopicNo.8)  Re[4]: メソッドの例外処理の取得方法に関して
□投稿者/ レン (5回)-(2008/08/12(Tue) 05:48:59)
開発者のユーザー向けに動作を変えるべきなのですね。
勉強になります。
例外クラスの作成について、もう少し勉強してみます。
ご教示ありがとうございました。
解決済み
引用返信 編集キー/
■23253 / inTopicNo.9)  Re[5]: メソッドの例外処理の取得方法に関して
□投稿者/ レン (6回)-(2008/08/12(Tue) 05:49:41)
ありがとうございます。
参考になりました。
解決済み
引用返信 編集キー/


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

このトピックに書きこむ

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

管理者用

- Child Tree -