4D Japan Knowledge Base

Why you should use a custom error handler

あなた独自のエラーハンドラーをインストールすることの利点は、十分評価されていないかもしれません。

システムレベルのエラーが起きた時の4Dのデフォルトの振る舞いは、直ちにCurrent Processのコード実行を終了することです。これは、4Dデバッガーで「Abort」ボタンをクリックするのと同じです。4Dは、エラーが起きた状況ではもはや安全に処理を実行できるかどうか分らないと判断し、データにダメージを与えてしまうリスクを冒すよりは、コードの実行を終了させてしまうのです。

あなたがもし「コードの実行を終了させずにエラー処理をしたい」と考えるなら、独自のエラーハンドリングメソッドをON ERR CALLを使ってインストールします。通常の処理へ復帰する前にエラー状況に応じた適切な対処を行うコードを書くのはプログラマーの責任です。

ストアドプロシージャを使っているのなら、それは4D Server上で実行されているので、さらに独自エラーハンドリングの重要性は高まります。4D Server上ではエラーが起きた時にエラーダイアログは一切表示しません。従って、エラーが発生して、メソッドが終了したのか、正常に処理を実行して終了したのかを判別することが出来ません。もしエラーが発生していたのであれば、ふさわしい処理を行っておかないと、データの整合性を保てなくなるかも知れません。

この問題を回避するにも、独自エラーハンドラーをインストールして適切なリカバリー処理を行うべきでしょう。最も良いのはON ERR CALLをON SERVER STARTUPデータベースメソッドで実行することです。

4th Dimension、4D Clientでエラーハンドリングメソッドを使っていた方は、各プロセスに各々個別のエラーメソッドをインストールするというルールをご存知でしょう。しかし4D Server上では、すべてのトリガと幾つかのデータベースメソッドは一つのエラーハンドラーを共有します。つまり、ON ERR CALLをON SERVER STARTUPデータベースメソッドで実行するということは、すべてのトリガの為のエラーハンドラーをインストールすることに他なりません。