- PR -

ArgumentException,ArgumentNullExceptionでパラメータ名とメッセージを入力したときメッセージだけ取り出

«前のページへ 1|2|3|4 次のページへ»
投稿者投稿内容
餅宮餅吉
ベテラン
会議室デビュー日: 2005/03/04
投稿数: 57
お住まい・勤務地: 月餅のうまい店の隣
投稿日時: 2005-07-01 10:01
引用:

にしざきさんの書き込み (2005-07-01 08:41) より:
> 名前や住所の各メソッドやプロパティを呼び出すのに１つ１つtry-catchでくくって
でなく、「呼び出す」前に調べてから使うっていうのが「流儀」だそうです。

たとえば、bool IsValidAddress, IsValidName, ... を実装するとか。

個人的な印象：
例外時の詳細な情報を返したいのであれば、例外文字列をパースするよりも
専用の例外クラスを作ってそれを返すほうがいいと思います。

</font>

　新しく例外クラスを作成したほうが言いというのには同意いたしますが、値をチェックするメソッドを新たに実装するというのは、チェックした時とセットした時とはでは値が異なる可能性がある場合は良いとは思えません。
　又、事前チェック(bool IsXXXで実装)で不正になった場合に、再度ユーザに表示する為の値を取り直すようなメソッドを実装しなければならいと思いますが、それよりなら、値セットするメソッド内でチェックし、システム利用者に分るメッセージをセットして例外をスローし、それを表示したほうが自然に思えますが如何でしょうか？
もとべえ
会議室デビュー日: 2004/09/17
投稿数: 16
投稿日時: 2005-07-01 10:08
にしざきさん。レスありがとうございます。

> 名前や住所の各メソッドやプロパティを呼び出すのに１つ１つtry-catchでくくって
でなく、「呼び出す」前に調べてから使うっていうのが「流儀」だそうです。

なるほど、確かに事前に調べて使えば住所や名前については問題なさそうです。ただ、今回とは直接関係がないかもしれませんが、引数のチェックにファイルの存在のチェック等が入っている場合などにはどうなのでしょうと少し思いました。

もちろんそのプロパティないしメソッドでも同様のファイルの存在チェックを行って格納するかと思いますが、チェックするメソッドとセットするプロパティの間にファイルが削除されることも考慮に入れると（ほとんどないと思いますが・・・）、例外に対して、結局セットするプロパティをtry-catchでくくらないといけません。まぁ、１回チェックしているのでセットするプロパティでチェックしないと言うこともありですが、誤ってチェックしないで使用してしまう場合もあるでしょうし・・・。

独自の例外クラスを返すというのも大ありだと思います。最初例外からメッセージが抜き出せないので、派生した例外クラスを作って返そうとも思っていました。

これも１つの答えかと思います。ただ、例外はエンドユーザに見せないというのも「流儀」・・・。「流儀」って難しいですね。
えんぞ@？
ぬし
会議室デビュー日: 2004/07/06
投稿数: 271
お住まい・勤務地: はまっこ
投稿日時: 2005-07-01 11:02
自分はどちらかといえば、餅宮餅喜さん的な考えかな。
引用:

もとべえさんの書き込み (2005-07-01 10:08) より:
ただ、例外はエンドユーザに見せないというのも「流儀」・・・。「流儀」って難しいですね。

流儀というより、例外をエンドユーザに見せてもな「なんじゃこれ？意味わからん」ってなるかと。
「FileNotFoundException...」というメッセージをユーザに見せてもあまり意味はないでしょう。「ファイルが見つかりませんでした」の方がエンドユーザにとっては一番よいのでは。
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2005-07-01 11:12
引用:

もとべえさんの書き込み (2005-07-01 10:08) より:
にしざきさん。レスありがとうございます。

もちろんそのプロパティないしメソッドでも同様のファイルの存在チェックを行って格納するかと思いますが、チェックするメソッドとセットするプロパティの間にファイルが削除されることも考慮に入れると（ほとんどないと思いますが・・・）、例外に対して、結局セットするプロパティをtry-catchでくくらないといけません。まぁ、１回チェックしているのでセットするプロパティでチェックしないと言うこともありですが、誤ってチェックしないで使用してしまう場合もあるでしょうし・・・。



こういった想定外の動作、想定外のコーディングを考慮した局所的なcatchしない方が良いですよ。
バグが隠れちゃいます。（誤ってチェックしないで使用してしまう場合ってのはバグですよね。）
_________________
「伝える」とは「人に云う」と書く。
http://d.hatena.ne.jp/NAL-6295/
もとべえ
会議室デビュー日: 2004/09/17
投稿数: 16
投稿日時: 2005-07-01 11:22
引用:

流儀というより、例外をエンドユーザに見せてもな「なんじゃこれ？意味わからん」ってなるかと。
「FileNotFoundException...」というメッセージをユーザに見せてもあまり意味はないでしょう。「ファイルが見つかりませんでした」の方がエンドユーザにとっては一番よいのでは。


えんぞ@？さんのおっしゃるとおりFileNotFoundException...を表示させても意味はありません。ただ、方法の１つとして、例えばFileNotFoundExceptionを自分のクラスで発生させるときのMessageに「ファイルが見つかりませんでした」と書いて、それをcatchしたところにその内容をMessageBox.Show(this, e.Message)みたいな感じでエラーが表示させられれば、事足りるのでは？と思いました。そうした方がすっきりと例外を発生するオブジェクトを使用できますので…。

あれ？スタートに戻ってる？

[ メッセージ編集済み 編集者: もとべえ 編集日時 2005-07-01 11:27 ]
もとべえ
会議室デビュー日: 2004/09/17
投稿数: 16
投稿日時: 2005-07-01 11:51
NAL-6295さん。レスありがとうございます。

引用:

こういった想定外の動作、想定外のコーディングを考慮した局所的なcatchしない方が良いですよ。
バグが隠れちゃいます。（誤ってチェックしないで使用してしまう場合ってのはバグですよね。）


これも方法の１つですね。チェックルーチンを使用したかをチェック（インスタンス内のフラグをチェックしたら立てておく？）してから値をインスタンスのメンバにセットする。そうすれば、確かにtry-catchを使用しなくても良さそうですが、ただ、インスタンスに次のデータをセットする際にはそれらのフラグをクリアしてから使用する必要があって、さらに、メンバ数分だけフラグを用意しないといけませんね。

NAL-6295さんの例外の考え方は想定外か想定内のコーディングかという視点からですね。いろいろな考え方があっておもしろいです。

私の場合はエラーを例外に置き換えているという感じでしょうか？だからこそエラーメッセージをダイアログに表示したいという方法に持っていってしまうのですよね。特に自分で作成したクラス（特にGUIと関係ないところ）については…。
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2005-07-01 11:57
引用:

もとべえさんの書き込み (2005-07-01 11:51) より:
NAL-6295さん。レスありがとうございます。

引用:

こういった想定外の動作、想定外のコーディングを考慮した局所的なcatchしない方が良いですよ。確実な後処理が必要ならfinalyは必要ですが・・・。
バグが隠れちゃいます。（誤ってチェックしないで使用してしまう場合ってのはバグですよね。）


これも方法の１つですね。チェックルーチンを使用したかをチェック（インスタンス内のフラグをチェックしたら立てておく？）してから値をインスタンスのメンバにセットする。そうすれば、確かにtry-catchを使用しなくても良さそうですが、ただ、インスタンスに次のデータをセットする際にはそれらのフラグをクリアしてから使用する必要があって、さらに、メンバ数分だけフラグを用意しないといけませんね。


そういう意味ではないです。
想定外の例外は上まで潰さないで一番上でcatchしてあげれば良いという考えです。

#今回のファイルの存在可否に関していえば、例外がどうのというよりも、File.Existsを使うのでしょうが。


_________________
「伝える」とは「人に云う」と書く。
言葉を尽くさなければ何も伝わらない。

[ メッセージ編集済み 編集者: NAL-6295 編集日時 2005-07-01 12:03 ]
きくちゃん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 854
お住まい・勤務地: 都内某所
投稿日時: 2005-07-01 13:13
＃どっかで書いたような気もしますが…。

.NET の場合、例外は、開発者に対して異常を伝えるための機構だと考えています。
ですから、エンドユーザが直接扱うようなアプリケーションでは、基本的に例外を発生させないようにプログラミングすべきであって、それに頼るような書き方をしちゃぁ、いけないんじゃないかと。

アプリケーションに Try 〜 Catch を書くのは、「安全装置」を置いとくようなもんだと思ってます。
キャッチして何するかといえば、可能であれば例外の種類に応じて復旧を試みて、想定外の例外なら取り敢えず軟着陸させてバグ修正の手がかりとしてログを残すとかでしょうか。基本的に。

逆にクラスライブラリでは、独自の例外定義しまくってますし、投げまくってます。
Catch しないでTry 〜 Finally だけの処理ってのも意外と多かったりします。
それ以上の事は、ライブラリを利用して開発する人間（自分も含む）がどうにかすればいい話なので。
と同時に、なるべく例外の発生を回避できるように、検査メソッドや IsXxxxxx みたいなプロパティも用意するよう心がけていますけどね。
«前のページへ 1|2|3|4 次のページへ»

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