- PR -

多数の例外が発生するメソッドのcatch

1|2 次のページへ»
投稿者投稿内容
頭脳パン
ベテラン
会議室デビュー日: 2003/04/03
投稿数: 89
投稿日時: 2006-08-23 16:25
Javaから移行してきた組なのですが、どうもMSDNを見ると
メソッドが発生させる可能性のある例外の種類がJavaに比べて多いような。
１０種類以上の例外がある場合だってありますね。

Exceptionでcatchしてしまえばそれでおしまいなのですが
コード規約的には、親クラスでcatchは悪とされています。

そんな場合どうされていますか？

１）Exceptionでcatch
２）発生しそうなものだけcatchに記述。
３）全ての例外をcatchに記述。
ひろれい
ぬし
会議室デビュー日: 2006/03/02
投稿数: 486
お住まい・勤務地: 万博開催地
投稿日時: 2006-08-23 16:38
Web アプリでしょうか、Windows アプリでしょうか。
私も Web アプリの例外処理で考えたことがありました。参考までに、その時のスレを貼っておきます。

　　【ASP.NET】クラス内で発生したエラーの捕らえ方
一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2006-08-23 17:09
その例外が発生した場合の対応を準備しておく(つまりコードを書く)価値のあるものはそいつをキャッチして処理。
想定されていないもの、対応する価値の無いものはあるレベルで全てをキャッチ。

例えば、OutOfMemoryExceptionはコンピューターの状態により常に起こり得ます。起こることが想定できますが、全てのメソッドにこれをキャッチするtry-catchを書くなんてことはしません。
頭脳パン
ベテラン
会議室デビュー日: 2003/04/03
投稿数: 89
投稿日時: 2006-08-23 17:20
＞Web アプリでしょうか、Windows アプリでしょうか。
Webアプリからもコンソールからも呼ばれる共通処理です。

例外は、一応、catchしたら
その共通処理用の例外にラップして再スローする予定です。

そのcatchの仕方をどうしようかなと。

>例えば、OutOfMemoryExceptionはコンピューターの状態により常に起こり得ます。
参考になるかもです。Javaでも検査例外ありなしの違いはありますが
OutOfMemoryExceptionのcatchなんて書かないですもんね。

例として「Activator.CreateInstance」をあげてみますが
これは、１０種類の例外発生の可能性があります。

私の作成する処理は、CreateInstanceにCOMを指定することはないので
これをそもそもcatchしない等が考えられるでしょうか。
かるあ
ぬし
会議室デビュー日: 2003/11/16
投稿数: 1190
お住まい・勤務地: センガワ→ムサシノ
投稿日時: 2006-08-23 17:55
単にそのメソッド内で処理できるものだけを、
catch すればいいのかなーと思うのですがどうでしょうか

処理できない例外さえ 共通の例外クラスに
すり替えてスローする必要ってあるんでしょうか
頭脳パン
ベテラン
会議室デビュー日: 2003/04/03
投稿数: 89
投稿日時: 2006-08-23 18:12
例えば、CreateInstanceだと
COMの指定は考えられないけど、処理できちゃいます。
（インスタンス化できないクラス名を指定したという意味で）
そうすると、catch節が１０個並ぶことに。
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-08-23 19:28
引用:

例えば、CreateInstanceだと
COMの指定は考えられないけど、処理できちゃいます。
（インスタンス化できないクラス名を指定したという意味で）
そうすると、catch節が１０個並ぶことに。

捕まえても、たいした処理は出来ないですよね。
.NET の例外は殆ど全て、非検査例外という考えだと思います。

それら１０個の例外は、デバッグ時、テスト時に一切出なくなるように実装します。全部catchするという意味ではなく、そういうロジックを書きます。Activator.CreateInstance に渡す引数に null が入らないようにする、抽象クラスを渡さないようにする、等です。

で、テストが終了してリリースに入っても、 catch しないで放置。そうして稼動時にも不具合が理解できるようにしておきます。

ユーザーに例外情報を見せても意味ないので、一番外（Application.ThreadException や HttpApplication.Error 等）で捕まえて、ログに記述しておくなりしておいて、ユーザーにはヤンワリとエラーを通知する、というのが定石でしょうか。
_________________
囚人のジレンマな日々
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2006-08-23 19:39
引用:

囚人さんの書き込み (2006-08-23 19:28) より:
引用:

例えば、CreateInstanceだと
COMの指定は考えられないけど、処理できちゃいます。
（インスタンス化できないクラス名を指定したという意味で）
そうすると、catch節が１０個並ぶことに。

捕まえても、たいした処理は出来ないですよね。
.NET の例外は殆ど全て、非検査例外という考えだと思います。

それら１０個の例外は、デバッグ時、テスト時に一切出なくなるように実装します。全部catchするという意味ではなく、そういうロジックを書きます。Activator.CreateInstance に渡す引数に null が入らないようにする、抽象クラスを渡さないようにする、等です。

で、テストが終了してリリースに入っても、 catch しないで放置。そうして稼動時にも不具合が理解できるようにしておきます。

ユーザーに例外情報を見せても意味ないので、一番外（Application.ThreadException や HttpApplication.Error 等）で捕まえて、ログに記述しておくなりしておいて、ユーザーにはヤンワリとエラーを通知する、というのが定石でしょうか。



そうですね。
私もそうしています。

その場でキャッチしてもよい例外は、
業務上例外が発生する事が想定され、
その後も正常な処理を行いたい場合のみで、
それ以外は、囚人さんの仰ってるとおり

引用:

ユーザーに例外情報を見せても意味ないので、一番外（Application.ThreadException や HttpApplication.Error 等）で捕まえて、ログに記述しておくなりしておいて、ユーザーにはヤンワリとエラーを通知する、というのが定石でしょうか。


となります。
1|2 次のページへ»

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