[[Open棟梁>https://github.com/OpenTouryoProject]] wiki

-[[戻る>アプリケーション設計のポイント]]

*目次 [#b1b12edc]
#contents

*概要 [#pf4a927d]
1.1.	例外処理方針
”棟梁”に組み込まれた例外処理の仕組みを利用する。以下に、例外処理の基本方針を示す。

*例外処理の処理フロー [#bae9594d]
例外処理の処理フローを、シーケンス図を使用して示す。例外処理の処理フローは、プログラムの最下層で例外がスローされた場合、次の流れで例外が伝播し、最上位層に伝わるようになっている。ただし、実際は、フレームワークで用意した「例外の型」毎に、処理フローが個別に設計されている。

なお、2層C/Sの例外処理の処理フローでは、「業務例外」の場合にトランザクションのロールバック ＆ 接続切断をしない（そのまま継続）。


*例外の種類 [#va9dc24d]

**業務例外 [#s1d87ff0]
業務的なエラーを通知するための例外

**システム例外 [#ua602d39]
環境上の問題などで発生する例外であるが、アプリケーションに於いて原因を明確にできるもの。

**その他、一般的な例外 [#ydc9bed7]
バグや環境上の問題で発生する想定外の例外（ランタイム エラー）。別途、発生原因の調査が必要。

***業務続行の可・不可 [#j3817819]

***業務例外 [#t7b9a154]
-業務続行可能
-元の画面に戻るか、任意の業務画面まで戻るなどして業務続行。

***システム例外 [#u7d1fbce]
-業務続行不可能
-汎用エラー画面に遷移して業務を停止する（か、ユーザに確認する）。

***その他、一般的な例外 [#x38d0db3]
-業務続行不可能
-汎用エラー画面に遷移して業務を停止する（か、ユーザに確認する）。

*例外処理の基本方針 [#xb6f58da]
例外のtry ～ catchは、”Open棟梁”側で処理するため、業務プログラムではtry ～ catchしない。

P層フレームワークを持たないリッチクライアント技術を使用する場合、

-Application.ThreadException
-.UnhandledException
-.DispatcherUnhandledException

イベントのハンドラを併用する。



（４）	エラー メッセージの表示方針
・	「業務例外」		：（プロジェクトによる）
・	「システム例外」		：（アーキテクチャ・プロジェクトによる）
・	「その他、一般的な例外」	：（アーキテクチャ・プロジェクトによる）

（５）	エラー ログの出力方針
・	「業務例外」		： エラー ログではなく、ワーニング ログを出力する。
・	「システム例外」		： 「システム例外」の例外情報をエラー ログに出力する。
・	「その他、一般的な例外」	： 「その他、一般的な例外」の例外情報をエラー ログに出力する。
 
以下に各例外の型と、具体的な例外との対応を示す。

表３．１　各例外の型と、具体的な例外との対応
項番	例外の型	説明
１	業務例外	業務続行可能なエラー用の例外をスローしたり、ハンドルしたりする。例えば、以下に列挙した、リトライ可能なエラーは、「業務例外」型を使用して例外をスローし業務を続行する。
・	関連チェック エラー
・	更新件数０件
（タイムスタンプ アンマッチ）
・	追加時のキー重複
・	デッドロック
・	ロックタイムアウト
・	コマンドタイムアウト
・	．ｅｔｃ
２	システム例外	業務続行不可能なエラー用の例外をスローしたり、ハンドルしたりする。例えば、以下に列挙した、アプリケーションで検出したが、リトライ不可能 or リトライさせたくないエラーは、「システム例外」の型を使用して例外をスローし（基本的に）業務を停止する。
・	リトライ不可能な、業務的なデータ不整合などのエラー
３	その他、一般的な例外	ランタイム エラーなど、ＵＰで特別に検知しない例外。この例外が発生した後、例外の振替など特別な措置を取らない限りリトライ不可能であり、（基本的に）業務を停止する。

ここでのリトライは、「UIからのリトライ」、「プログラム内でのリトライ」の両方を指すが、いずれもトランザクション・ロールバック後のリトライを指す。
（プログラム・レベルのリトライや、同一トランザクション内のリトライは、リトライ回数・間隔を調整したとしても有用になり難いので）
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS