4
  1. エラーロギングコードが失敗した場合はどうしますか？
  2. 現在機能していることをどのように確認しますか？
  3. それが機能していないかどうかをどうやって知るのですか？
  4. 実稼働環境での動作をどのようにテストしますか？
  5. 他のすべてが失敗した場合、例外をスローする必要がありますか？

以下のコードは、Microsoftのエンタープライズライブラリロギングアプリケーションブロックを使用しています。どうやってそれを「より良く」するのですか？

using Microsoft.Practices.EnterpriseLibrary.Logging;

class Program
{
    static void Main(string[] args)
    {
        try
        {
            // Trying to write some data to the DB
            ...
        }
        catch (Exception ex)
        {
            LogHelper.LogException(ex, "Trying to write to the DB");
        }
    }
}

public class LogHelper
{
    public static void LogException(Exception ex, string exceptionType)
    {
        try
        {
            // Simplified version, only logging the message
            Logger.Write(exceptionType);
        }
        catch
        {
            // What do you do here???
        }
    }
}
4

3 に答える 3

5

私のアプリは通常、エラーに対して 2 つのことを行います。1 つ目は、ローカル ログ ファイルに書き込むことです (何らかの種類のデータベース ログも使用している場合でも)。次に、サポート用に設定された配布リストにエラーの電子メールを送信します。

そのため、データベース ログの書き込みに失敗した場合でも、エラーはローカル ログ ファイルに残り、電子メールでも送信されます。

電子メールが失敗した場合でもエラーがログに記録されるため、後で問題をトラブルシューティングできます。

それよりも耐障害性を高めることは、非常にミッションクリティカルなアプリケーションである IMHO にとってのみ価値があります。

于 2009-04-01T18:03:56.517 に答える
3

関連する質問の回答を参照してください。

他のすべてが失敗した場合は、catch ブロックに「最後の手段のログ」を入れてください。これが失敗する可能性が非常に低い場所にあるテキスト ファイルに例外を記録します。この最後の手段であるログ記録が別の例外をスローして失敗した場合は、その例外を飲み込むか、アプリを終了してエラーをメッセージ ボックスとして表示することができます。

この特定の (例外的な) ケースでは、例外を飲み込むことがアプリを終了させない唯一の方法です。

于 2009-04-01T18:23:57.263 に答える
0

私はログファイルを作成するだけでなく、消えることのない共通のアドレスに電子メールを送信します。どちらも防弾ではありませんが、メールシステムがダウンしたり、メールサーバーが変更されたりした場合は、それを知っていると思います。データベースとフラットファイルの両方に書き込み、メールを送信するアプリがいくつかあります。したがって、3つのうちの1つが機能します。私のアプリの1つがログ用のdbに書き込んでいることがわかりました。キャッチでは、同じdbに書き込んでおり、db接続の変更が原因でアプリが失敗していることがわかりました。dbの代わりにemailを実行するcatchステートメントを変更するようにしました。私がフラットファイルで抱えている唯一の問題はファイルシステムストレージです。ログ用のフラットファイルを書き込むアプリケーションがたくさんあるので、常にバックアップして保存するか、単に削除するだけです。

于 2009-04-01T18:34:26.893 に答える