- 追加された行はこの色です。
- 削除された行はこの色です。
[[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
イベントのハンドラを併用する。
(4) エラー メッセージの表示方針
・ 「業務例外」 :(プロジェクトによる)
・ 「システム例外」 :(アーキテクチャ・プロジェクトによる)
・ 「その他、一般的な例外」 :(アーキテクチャ・プロジェクトによる)
(5) エラー ログの出力方針
・ 「業務例外」 : エラー ログではなく、ワーニング ログを出力する。
・ 「システム例外」 : 「システム例外」の例外情報をエラー ログに出力する。
・ 「その他、一般的な例外」 : 「その他、一般的な例外」の例外情報をエラー ログに出力する。
以下に各例外の型と、具体的な例外との対応を示す。
表3.1 各例外の型と、具体的な例外との対応
項番 例外の型 説明
1 業務例外 業務続行可能なエラー用の例外をスローしたり、ハンドルしたりする。例えば、以下に列挙した、リトライ可能なエラーは、「業務例外」型を使用して例外をスローし業務を続行する。
・ 関連チェック エラー
・ 更新件数0件
(タイムスタンプ アンマッチ)
・ 追加時のキー重複
・ デッドロック
・ ロックタイムアウト
・ コマンドタイムアウト
・ .etc
2 システム例外 業務続行不可能なエラー用の例外をスローしたり、ハンドルしたりする。例えば、以下に列挙した、アプリケーションで検出したが、リトライ不可能 or リトライさせたくないエラーは、「システム例外」の型を使用して例外をスローし(基本的に)業務を停止する。
・ リトライ不可能な、業務的なデータ不整合などのエラー
3 その他、一般的な例外 ランタイム エラーなど、UPで特別に検知しない例外。この例外が発生した後、例外の振替など特別な措置を取らない限りリトライ不可能であり、(基本的に)業務を停止する。
ここでのリトライは、「UIからのリトライ」、「プログラム内でのリトライ」の両方を指すが、いずれもトランザクション・ロールバック後のリトライを指す。
(プログラム・レベルのリトライや、同一トランザクション内のリトライは、リトライ回数・間隔を調整したとしても有用になり難いので)