1

現在サポートしているアプリケーションにエラーコードを組み込むことを検討してきましたが、いくつかの一般的な質問がありました。

私がコードの使用に傾倒している理由は、プログラムで修正することができない、アプリケーション内の重大な問題を少なくとも1つ特定したためです。この問題は非常にまれですが、発生した場合、ユーザーに深刻なダウンタイムが発生する可能性があります。これを修正するには、問題に精通しているサポート担当者に直接連絡する必要があります。

アプリケーションで可能な限り最善を尽くすために、Windowsイベントログに情報を書き込んで、サポートスタッフに破損したデータを示し、一般的な「サポートに電話してください」というプロンプトをユーザーに表示します。

エラーコードを追加して、サポートがイベントビューアで特定のエラーをより迅速に見つけられるようにします。

それで、最初の質問:これは許容できるアプローチですか、それとも私が考慮していない別のアイデアがありますか?

次に、エラーコードを使用する場合、ソリューションでエラーコードを管理するための最良の方法は何ですか?交差しない整数グループがブロックされたエラーコードファイルを各プロジェクトに含めますか(yuck)?エラーコード(yuck)を保持するための新しいプロジェクトを作成しますか?

エラーコードをどのように最適に管理するかについては、これまでよくわかりませんでした。また、私が取り組んだ2つのプロジェクトで、これをクリーンな方法で実行したことはありません。私はそれらを避けたいのですが、もし私がそれらを使わなければならないのなら、私は何が最もうまくいくか知りたいです。

4

1 に答える 1

1

エラー コードは、考えられるすべての既知のエラー シナリオを簡潔に説明する方法として、つまり、ローカリゼーションと中国語のささやきがトラブルシューティング プロセスを混乱させないようにする方法として存在します。

エラー状態ごとに人間が読める一意のエラーメッセージがあると仮定すると、エラーコードのデータベースを維持する必要はなく、正規の英語文字列のハッシュとして計算するだけです (それがデフォルト言語であると仮定します)。 . ローカライズされたバージョンを追加する場合は、英語の文字列をダイジェストのベースとして使用し続けてください。

テクニカル コールを受け取ったら、ハッシュ コードに一致する文字列を見つけるだけで済みます。これは、ユーティリティ プログラムを使用して自動的に実行できます (Reflection to the rescue)。

または、ユーザーに表示されるすべての例外が、開発者の責任となる必須のエラー コード コンストラクター引数を持つ独自の Exception サブクラスによってカプセル化されていることを確認します。

于 2012-08-08T23:03:27.427 に答える