J2EE アプリケーションでのエラー処理について質問があります。現在のアプリケーションは多くのユーザーによって使用されており、その結果、多くのサポート チケットを取得しています。これらのチケットのほとんどはユーザー関連ですが、5 ～ 10% はシステム関連の例外、未処理のエラーなどです。
コードには基本的な例外処理チェックがありますが (作業が必要です)、私の経験から、一般的なメッセージをユーザーに表示しても、トラブルシューティング プロセスを迅速化するのには役立ちません。
私が探しているのは、適切なエラー処理の設計パターンに関する推奨事項です。シナリオを考えてみましょう。
- コードにエラーがあります
- エラー処理
- ユーザーには、特定のエラー コードを含む非技術的なエラー メッセージが表示されます。
- テクニカル サポート以外のチームは、このエラー コードを使用して、アプリケーション内でこれが発生した領域 (ページ、セクションなど) と、ユーザーが何をしていた可能性があるか (カスタマー サポート リファレンス ガイドで開発チームが事前に入力した情報) を確認できます。
- 技術サポート チームは、コードを使用して、クラス/JSP などと、その例外をトリガーしたコード行をゼロにすることができます。
- ほとんどの(すべてではない) Tomcat stdout エラーがユーザー セッションによってログに記録されるロギング モジュールを使用します。ユーザーが受け取るエラー コードに、ログ ID が存在する場合はそれを含めて、技術チームがそれを確認できるようにします。それも。
基本的に私が興味を持っているのは、サポートの分析、説明、調査のサイクルを短縮し、すべての部門がそれぞれの仕事をより迅速に開始できるように、すぐに情報にアクセスできるようにすることです。
- カスタマー サポートは、このエラー コードについて定型的な説明を提供したり、ユーザーが実行できる代替手順を提示したりできます。
- 技術チームは、コード行またはその行をトリガーしたユーザーの操作のトラブルシューティングを開始できます。
必須の各エラー コードは、各部門に必要な次のステップをトリガーし、事実上、問題の調査段階を減らし、解決段階に移行します。
上記が良い考えであるかどうかはわかりません。そのようなニーズに適した「デザインパターン」についての提案をいただければ幸いです。または、それが一見の良いルートでさえある場合。
前もって感謝します。
SP