[[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からのリトライ」、「プログラム内でのリトライ」の両方を指すが、いずれもトランザクション・ロールバック後のリトライを指す。 (プログラム・レベルのリトライや、同一トランザクション内のリトライは、リトライ回数・間隔を調整したとしても有用になり難いので)