- PR -

例外処理の書き方について

1|2 次のページへ»
投稿者投稿内容
あや☆
常連さん
会議室デビュー日: 2005/07/28
投稿数: 36
投稿日時: 2005-10-21 10:57
いつもお世話になっております。
C#.NETでWEBアプリの開発をしています。

例外処理の書き方について質問があります。
現在のソースには、データベース関連の処理やファイル操作など、明らかに例外の発生する可能性がある場所は、try-catchで例外処理を記述しているのですが、
実際には開発者にとって想定外の例外が発生することもあると思います。（メモリ不足とか？）
全てのソースをtryで囲み、catch(Exception)するのが、一番確実だとは思うのですが、
いいプログラムとは言えない気がします。

そこで、C#での開発経験のある方、どのように例外処理を記述しているのかを教えて下さい。
周りにC#を使ったことがある人がいなく、私自身もtry-catch構文を使う言語での開発経験がないため、一般的にはどのようなものなのか分からなくて困っています。
どうぞよろしくお願いいたします。
たつごろー
ぬし
会議室デビュー日: 2004/10/25
投稿数: 496
投稿日時: 2005-10-21 11:06
例外を拾って対処できる・その価値がある、というところにだけ書いています。
全部拾って全部対処というのは現実的ではないと思います。

_________________
たつごろー
codeseek
こみゅぷらす
kanai
ベテラン
会議室デビュー日: 2004/09/13
投稿数: 98
投稿日時: 2005-10-21 11:08
.NET TIPS「適切に処理されなかった例外をキャッチするには？」
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-10-21 11:24
引用:

kanaiさんの書き込み (2005-10-21 11:08) より:
.NET TIPS「適切に処理されなかった例外をキャッチするには？」

Web アプリケーションでも出来るんですか?

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-10-21 11:34
どもです。がると申します。
引用:

実際には開発者にとって想定外の例外が発生することもあると思います。（メモリ不足とか？）
全てのソースをtryで囲み、catch(Exception)するのが、一番確実だとは思うのですが、
いいプログラムとは言えない気がします。

一般的、というほど様々なソースコードを見ているわけではないのですが。
私は「必要なので」全てのソースをtryで囲っています。

特に「これ」といったデメリットがなければ、一番上位で
「どうしても想定しきれなかったthrow」をcatchするのも
よいのではないかと思うのですが。
どうでしょう？ ＞ あやさん ＆ 皆様
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-10-21 11:48
引用:

がるがるさんの書き込み (2005-10-21 11:34) より:

私は「必要なので」全てのソースをtryで囲っています。
特に「これ」といったデメリットがなければ、一番上位で
「どうしても想定しきれなかったthrow」をcatchするのも
よいのではないかと思うのですが。
どうでしょう？ ＞ あやさん ＆ 皆様

ある処理をメソッド化した場合には、それを丸ごと囲むことはたまにあります。
丸ごと囲むと言うと御幣がありそうです。
呼び出し先での例外は呼び出し元へ throw で通知しているので、呼び出し先を全部囲むのではなく、
呼び出し元で個々に囲んで対応しています。

ただ、エントリ ポイントなど大元で丸ごと囲むことはしませんね。
本当の意味で予期しない例外は、Application.ThreadException・Application_Error でやるべきだと思います。[　シグネチャを削除　]

[ メッセージ編集済み 編集者: じゃんぬねっと 編集日時 2006-09-19 14:41 ]
あや☆
常連さん
会議室デビュー日: 2005/07/28
投稿数: 36
投稿日時: 2005-10-21 14:18
返信ありがとうございます。
大変参考になりました。

「菊池 さんの Blog」、「NAL-6295 さんの Blog」も読んで、なるほど〜と思いました。
その中に、global.asaxのApplication_Errorイベント内にエラーをcatchすると良いというようなことが書かれていました。
確かに、どこかで例外が発生すると、ここのソースにとぶようです。
そこで、予期せぬ例外が起こった場合は、Application_Errorイベントでメッセージを出せればいいのではないかと思ったのですが、
他のページで使っているメッセージが出すコードを書いても、以下のようなコンパイルエラーが出ます。
「静的でないフィールド、メソッド、またはプロパティ 'System.Web.UI.Page.RegisterStartupScript(string, string)' で、オブジェクト参照が必要です。」

コード
------------------------------------------------------------------------
protected void Application_Error(Object sender, EventArgs e)
{
string jsResult = "<script language='VBScript'>";
jsResult += "Var = MsgBox (\"エラーメッセージ。\", 48,\"エラー\")";
jsResult += "</script>";
Page.RegisterStartupScript("jsResultInCurrentWindow",jsResult);
}
-----------------------------------------------------------------------

それは、クラスの先頭で
public class Global : System.Web.HttpApplication と書いてあり、
他のページのようにSystem.Web.UI.Page　が書いていないからだと思うのですが、
単に、public class Global : System.Web.HttpApplication ,System.Web.UI.Page
というように書いても「インターフェイスリストの型がインターフェイスではありません」をいうエラーが出ます。
このような書き方ではダメなのでしょうか？

初歩的なことのような気がしますが、回避策をご存知の方は、教えていただけないでしょうか？
よろしくお願いします。
長文になってしまってすいません。。。
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2005-10-21 14:39
NAL-6295です。
こんにちは。

引用:

そこで、予期せぬ例外が起こった場合は、Application_Errorイベントでメッセージを出せればいいのではないかと思ったのですが、
他のページで使っているメッセージが出すコードを書いても、以下のようなコンパイルエラーが出ます。
「静的でないフィールド、メソッド、またはプロパティ 'System.Web.UI.Page.RegisterStartupScript(string, string)' で、オブジェクト参照が必要です。」



上記件についてですが、
まず、
Global自体はページではない。
という前提があり、その為、上記のような処理を実行させる事はできません。
では、どうしているのかというのを簡単に説明すると、
1.Appication_Errorでキャッチした例外をイベントログに登録しておく。
2.デバック時はセッションにエラー情報を保持。リリース時は何もしない。
3.Server.ClearErrorでエラーを消す。
4.エラー用のページを用意しておき、そちらにリダイレクトする。
(リリース時は、「ご迷惑をおかけしております。」ぐらいの表記。
　　デバック時は、例外情報を表記。)
というようなことを行っています。
1|2 次のページへ»

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