本のナビゲーション:.NETが異常処理を行う場合の原則的注意事項は前に書いてあります. try...catch...finally は、Try/Catchブロックがいつ設定されるかを知る.異常処理方法を関数から情報を返す手段としないでください.無視してはいけないエラーのための異常な使用 new Exceptionを投げ出すな()は、using を使用する.
構造エラー処理機構を使用しないでください.異常を使用せずに、業務ロジックを管理する指定された異常を取り込むべきです.異常を捕獲するだけでなく、何の処理もしないでください.将来のメンテナンスには不便です.ユーザ定義の異常を作成します.
類の設計は、正常使用において異常が発生しないようにするべきである.総括NETが異常処理を行う場合の原則注意事項
前に書く
異常処理は優秀なプログラムとシステムにとってはもちろんのこと、プログラムのメンテナンス性と丈夫性の増加異常処理がほしいなら、逃げられない話です.私はまだ下手ですが、頑張っています.
try…catch…finallyに異常が発生した時、異常がスタックに沿って上に伝達され、各Catchブロックはそれを処理する機会があります.Catch文の順番は重要です.特定の異常に対するCatchブロックを通常の異常Catchブロックの前に置くと、コンパイラがエラーを出す可能性があります.正確なCatchブロックを決定する方法は、異常の種類をCatchブロックに指定された異常名称と整合することである.特定のキャッチブロックがない場合、存在する可能性がある従来のキャッチブロックによって異常が捕捉される.共通言語ランゲージは、キャッチブロックが捕捉されていない異常を捕捉する.ライブラリの設定により、またはデバッグダイアログが表示されたり、プログラムの実行が停止され、異常情報を含むダイアログが表示されます. finally文は、異常が発生した場合でも、直ちに必要なオブジェクト(通常は外部リソースを保存するオブジェクト)のクリーンアップを確保することを目的とする.のこのようなクリーン機能の一例は、使用後に直ちにFileStreamに対してCloseを呼び出すことであり、公共の言語の実行を待つ間に当該オブジェクトをゴミ回収するのではなく、以下のようにする.上のコードをtry-catch-finally文に変換するためには、整理コードと作業コードを次のように分離する必要があります.static void CodeWithoutCleanup()
{
System.IO.FileStream file = null;
System.IO.FileInfo fileInfo = new System.IO.FileInfo("C:\\file.txt");
file = fileInfo.OpenWrite();
file.WriteByte(0xF);
file.Close();
}
OpenWrite()の呼び出し前に、tryブロック内でいつでも異常が発生する可能性があります.OpenWrite()の呼び出し自体も失敗する可能性がありますので、このファイルは私達が閉じることを試みている間にオープン状態にあるとは保証できません.finallyブロックは、Closeメソッドを呼び出す前にFileStereamオブジェクトがnullでないことを確認するためのチェックを追加しました.null検査がない場合、finallyブロックは自身のNull ReferenceExceptionを誘発する可能性がありますが、finallyブロックに異常が発生することはできるだけ避けなければなりません. finallyブロックでデータベース接続をオフにするのは別の良い選択です.データベースサーバが許可する接続数が限られている場合がありますので、できるだけ早くデータベース接続をオフにしてください.異常が発生して接続を閉鎖できない場合には、finallyブロックを使うのもゴミの回収を待つより良い選択です.static void CodeWithCleanup()
{
System.IO.FileStream file = null;
System.IO.FileInfo fileInfo = null;
try
{
fileInfo = new System.IO.FileInfo("C:\\file.txt");
file = fileInfo.OpenWrite();
file.WriteByte(0xF);
}
catch(System.UnauthorizedAccessException e)
{
System.Console.WriteLine(e.Message);
}
finally
{
if (file != null)
{
file.Close();
}
}
}
いつTry/Catchブロックを設置するか知っています.例えば、異常処理を用いずに発生する可能性のある条件をプログラム的に検査することができる.他の場合、異常処理を用いてエラー条件を捕捉するのは適切である.
以下の例は、if文を用いて接続がオフされているかどうかを確認する.接続が閉じられていない場合は、異常を引き起こすことなく、この方法を使用することができます. public int ExecuteNonQuery(string sql)
{
int res;
try
{
cmd = new SqlCommand(sql, GetConn());
res = cmd.ExecuteNonQuery();
}
catch (Exception)
{
throw;
}
finally
{
if (conn.State==ConnectionState.Open)
{
conn.Close();
}
}
return res;
}
は、以下の例では、接続が閉じられていないと異常を引き起こす.if(conn.State != ConnectionState.Closed)
conn.Close();
の具体的な選択方法は、予想されるイベントの発生頻度に依存する.イベントが異常であり、エラー(如意外のファイルの最後)であれば、異常処理を使ったほうがいいです.正常な状況で実行されるコードがより少ないからです.イベントが定期的に発生する場合は、プログラミング方法を使ってエラーをチェックしたほうがいいです.異常処理方法を関数から情報を返す手段としないでください.
これは最悪のデザインです.異常な処理が遅いだけでなく、コードの多くはtry/catchモジュールでコードを維持しにくいという意味です.適切なクラス設計は、通常の戻り値を提供することができる.もしあなたが危機の中で異常なデータを返したいなら、あなたの方法は多すぎる仕事をして分解しなければならないかもしれません.無視されてはいけないエラーのために異常を使います.
new Exceptionを投げ出さないでください()
例えばオブジェクトの現在の状態に応じて、属性セットまたは方法呼び出しが不適切であれば、InvalidOperation Exceptionが開始される.は、伝達されたパラメータが無効であれば、Agmennt ExceptionまたはAgment Exceptionから派生したクラスを誘発する.アメリカを使う
usingは、ステートメントとして、範囲を定義し、この範囲の末尾にオブジェクトを解放する.例えば try {
conn.Close();
}
catch(InvalidOperationException ex) {
//Do something with the error or ignore it.
}
構造なしエラー処理機構を使用しないでください.
はOn Error Gotoと似ています.異常を使わずに業務ロジックを管理する
この使用条件文.制御論理がif-else文によって簡単に実行されるなら、異常はコードの可読性と性能を低下させるために使用されなくてもよい.
指定された異常を捕獲すべきです. catch(Exception e)だけではなく、指定された異常を捕獲して性能、コードの可読性、および多くの面でメリットがあります.
異常を捕獲するだけではなく、将来のメンテナンスに不便です.
ユーザー定義の異常を作成によりカスタム異常を作成し、少なくとも3つの共通構造関数を使用します.は、次の例では、Exceptionから新たな異常クラスEmployee ListNotFoundExceptionを派生している.このクラスでは三つのコンストラクタを定義し,各コンストラクタは異なるパラメータを使用する. public int ExecuteNonQuery(string sql, SqlParameter[] paras)
{
int res;
using (cmd = new SqlCommand(sql, GetConn()))
{
cmd.Parameters.AddRange(paras);
res = cmd.ExecuteNonQuery();
}
return res;
}
ユーザ定義の異常を作成すると、異常がアプリケーションドメインにまたがって発生した場合を含む、異常なメタデータがリモートで実行されるコードに対して利用可能であることを確認しなければならない.例えば、アプリケーションドメインAがアプリケーションドメインBを作成し、後者が異常コードを実行すると仮定する.アプリケーション領域Aが異常を正確に捕獲し、処理するためには、アプリケーションドメインBに起因する異常なプログラムセットを見つけることができる必要がある.アプリケーションドメインBから発生する異常を含むプログラムセットがアプリケーションドメインBのアプリケーションベースディレクトリの下にある場合、アプリケーションドメインAのアプリケーションベースディレクトリの下にないと、アプリケーションドメインAは異常を見つけられなくなり、パブリック言語ライブラリはFileNotFoundExceptionを誘発する.このような状況を回避するために、異常情報を含むプログラムセットを2つの方法で展開することができる.は、2つのアプリケーション領域で共有されるパブリックアプリケーションベースにプログラムセットを置く.
-または-は、2つのアプリケーション領域が1つの共通アプリケーションベースを共有しない場合、異常情報を含むプログラムセットに強い名前で署名し、グローバルプログラムセットキャッシュに配置する.類の設計は正常使用中に異常を起こさないようにしなければならない.
は、例えば、FileStreamクラスが、ファイルの最後に到達したかどうかを判定する別の方法を開示する.これはファイルの最後を超えると異常を回避します.以下の例はファイルの最後までどうやって読むかを示します.Imports System
Public Class EmployeeListNotFoundException
Inherits Exception
Public Sub New()
End Sub 'New
Public Sub New(message As String)
MyBase.New(message)
End Sub 'New
Public Sub New(message As String, inner As Exception)
MyBase.New(message, inner)
End Sub 'New
End Class 'EmployeeListNotFoundException
締め括りをつける
異常処理は一つで、深い知識、合理的な使用は異常であり、プログラムのメンテナンス性、丈夫性を増加させます.私のこの文章はよくある異常処理の注意すべき状況をまとめただけです.まだ多くの場合、私が接触していないか、またはしばらくは思いつかなかったので、とにかくあなたの異常処理をできるだけあなたのプログラムのメンテナンス性と頑丈さのサービスにしてください. いらっしゃいませ.http://www.zblog.us/programing/net/exception-handling.html |趙傑のブログ