Open棟梁 wiki
1.1. 例外処理方針 ”棟梁”に組み込まれた例外処理の仕組みを利用する。以下に、例外処理の基本方針を示す。
例外処理の処理フローを、シーケンス図を使用して示す。例外処理の処理フローは、プログラムの最下層で例外がスローされた場合、次の流れで例外が伝播し、最上位層に伝わるようになっている。ただし、実際は、フレームワークで用意した「例外の型」毎に、処理フローが個別に設計されている。
なお、2層C/Sの例外処理の処理フローでは、「業務例外」の場合にトランザクションのロールバック & 接続切断をしない(そのまま継続)。
業務的なエラーを通知するための例外
環境上の問題などで発生する例外であるが、アプリケーションに於いて原因を明確にできるもの。
バグや環境上の問題で発生する想定外の例外(ランタイム エラー)。別途、発生原因の調査が必要。
例外のtry ~ catchは、”Open棟梁”側で処理するため、業務プログラムではtry ~ catchしない。
P層フレームワークを持たないリッチクライアント技術を使用する場合、
イベントのハンドラを併用する。
(4) エラー メッセージの表示方針 ・ 「業務例外」 :(プロジェクトによる) ・ 「システム例外」 :(アーキテクチャ・プロジェクトによる) ・ 「その他、一般的な例外」 :(アーキテクチャ・プロジェクトによる)
(5) エラー ログの出力方針 ・ 「業務例外」 : エラー ログではなく、ワーニング ログを出力する。 ・ 「システム例外」 : 「システム例外」の例外情報をエラー ログに出力する。 ・ 「その他、一般的な例外」 : 「その他、一般的な例外」の例外情報をエラー ログに出力する。
以下に各例外の型と、具体的な例外との対応を示す。
表3.1 各例外の型と、具体的な例外との対応 項番 例外の型 説明 1 業務例外 業務続行可能なエラー用の例外をスローしたり、ハンドルしたりする。例えば、以下に列挙した、リトライ可能なエラーは、「業務例外」型を使用して例外をスローし業務を続行する。 ・ 関連チェック エラー ・ 更新件数0件 (タイムスタンプ アンマッチ) ・ 追加時のキー重複 ・ デッドロック ・ ロックタイムアウト ・ コマンドタイムアウト ・ .etc 2 システム例外 業務続行不可能なエラー用の例外をスローしたり、ハンドルしたりする。例えば、以下に列挙した、アプリケーションで検出したが、リトライ不可能 or リトライさせたくないエラーは、「システム例外」の型を使用して例外をスローし(基本的に)業務を停止する。 ・ リトライ不可能な、業務的なデータ不整合などのエラー 3 その他、一般的な例外 ランタイム エラーなど、UPで特別に検知しない例外。この例外が発生した後、例外の振替など特別な措置を取らない限りリトライ不可能であり、(基本的に)業務を停止する。
ここでのリトライは、「UIからのリトライ」、「プログラム内でのリトライ」の両方を指すが、いずれもトランザクション・ロールバック後のリトライを指す。 (プログラム・レベルのリトライや、同一トランザクション内のリトライは、リトライ回数・間隔を調整したとしても有用になり難いので)