問題タブ [error-logging]

エラーを例外に変換する方法を見つけました。キャッチされない場合は適切に表示しますが、便利な方法でログに記録する方法がわかりません。それらを単にファイルに書き込むだけでは役に立ちませんよね？また、例外の原因がまだわからない場合、データベースにアクセスする危険がありますか?

私は何年にもわたって、次の問題パターンに頻繁に遭遇しました。

• 私は、スタンドアロン アプリケーションと、人々が他のアプリ内から使用できるコアのライブラリ バージョンで構成されるパッケージの複雑なコードを書いています。

• 私たち自身のアプリと、おそらくユーザーがコア ライブラリを使用して作成したアプリの両方が、バッチ モード (オフライン、スクリプト、リモート、および/またはコマンド ラインから) と対話型の両方で実行される可能性があります。

• ライブラリ/アプリは複雑で大量のランタイム入力を受け取り、重大なエラー メッセージ、入力構文の警告、ステータス メッセージ、実行統計など、さまざまなエラーのような出力が発生する可能性があります。これらはすべて付随的な出力であり、別の方法で別の場所に表示または保存されるアプリケーションの主な目的ではないことに注意してください。

• これらのいくつか (おそらく非常に深刻なもののみ) は、対話的に実行する場合、ダイアログ ボックスが必要になる場合があります。ただし、バッチ モードで実行する場合は、ユーザー入力を停止せずにログに記録する必要があります。また、ライブラリとして実行する場合、クライアント プログラムは明らかに、発生したエラーをインターセプトおよび/または調査する必要があります。

• Linux、Windows、OSX など、すべてクロスプラットフォームである必要があります。また、どのプラットフォームでもソリューションが奇妙にならないようにしたいと考えています。たとえば、stderr への出力は Linux では問題ありませんが、Windows では GUI アプリにリンクすると機能しません。

• ライブラリのクライアント プログラムはメイン クラスの複数のインスタンスを作成する場合があり、クライアント アプリが各インスタンスで個別のエラー ストリームを区別できると便利です。

• ライブラリ メソッドが単純な呼び出し (エラー コードや重大度、エラー メッセージを出力する printf のような引数) でエラーをログに記録するだけで十分であることに誰もが同意すると仮定します。論争の的となる部分は、これがクライアント アプリによってどのように記録または取得されるかです。

私はこれを何年にもわたって何度も行ってきましたが、解決策に完全に満足することはありません. さらに、実際にはユーザーにとってそれほど重要ではない種類のサブ問題です (ユーザーは何か問題が発生した場合にエラー ログを見たいと思っていますが、それを実装するための私たちの手法についてはあまり気にしていません) が、トピックはプログラマーを興奮させます。そして、彼らは常にこの詳細に途方もない時間を浪費し、完全に満足することは決してありません.

この機能を C++ API に統合する方法について知恵を持っている人はいますか、または受け入れられたパラダイムまたは優れたオープン ソース ソリューション (GPL ではありません。商用のクローズド アプリや OSS で使用できるソリューションが必要です) はありますか?プロジェクト）？

Bash でエラーを処理するためのお気に入りの方法は何ですか? 私が Web で見つけたエラー処理の最良の例は、William Shotts, Jr がhttp://www.linuxcommand.orgに書いたものです。

彼は、Bash でのエラー処理に次の関数を使用することを提案しています。

Bash スクリプトで使用する、より優れたエラー処理ルーチンはありますか?

短い質問: この例外はどういう意味ですか? 「EXC_BAD_ACCESS (0x0001)」

完全な質問: このエラー ログ情報 (およびここでは省略したスレッドの詳細) を使用して、このアプリのクラッシュを診断するにはどうすればよいですか? (注: クラッシュ ログや OS カーネルに関する専門知識はありません。)

この場合、私の電子メール クライアント (Eudora) は、明らかなシステム変更がなくても、起動直後に毎回クラッシュします。

C++ でのコーディングから C# への切り替えを行っています。C++ エラー ログ/レポート マクロ システムを、C# のようなものに置き換える必要があります。

私のC++ソースでは、私は書くことができます

LOGERR("何らかのエラー"); または LOGERR("入力 %s および %d のエラー", stringvar, intvar);

マクロとサポート ライブラリ コードは、(場合によっては varargs) 形式のメッセージを、ソース ファイル、ソース行、ユーザー名、および時刻と共にデータベースに渡します。後でユーザーに報告するために、同じデータがデータ構造にも詰め込まれます。

この基本的なエラー報告/ログ記録を行う C# コード スニペットまたは例へのポインタを持っている人はいますか?

編集: この質問をした時点で、私は .NET を初めて使用し、System.Diagnostics.Trace を認識していませんでした。System.Diagnostics.Trace は、当時私が必要としていたものでした。それ以来、ロギング要件がより大きく複雑なプロジェクトで log4net を使用してきました。その 500 行の XML 構成ファイルを編集するだけで、log4net は必要なことすべてを実行します:)

Windows では、どこにエラー ログ ファイルを書き込みますErrorLog.txtか? ファイルの書き込み権限のために、パスは基本ユーザーに開かれている必要があることに注意してください。

イベントログがエラーを書き込む可能性のある場所であることは知っていますが、「ユーザー」レベルの権限で機能しますか?

編集: 私は Windows 2003 をターゲットにしていますが、エラー ログをどこに書き込むかについての「一般的なガイドライン」を持つような方法で質問を投げかけていました。
EventLog に関しては、Windows イベント ログにログを記録したい ASP.NET アプリケーションで以前に問題が発生したことがありますが、セキュリティ上の問題があり、心痛がありました。（私が抱えていた問題は覚えていませんが、あったことは覚えています。）

私は現在、海外に展開されるかなり大規模な多層アプリに取り組んでいます。展開後に倒れたり爆発したりしないことを願っていますが、これを100％確信することはできません. そのため、ログ ファイルをリクエストして、何が問題で、その理由を正確に把握できると便利です。

基本的に、タイトルが示すように、いつ、何をログに記録するか知りたいですか? アプリがダウンした場合に何が起こったのかを簡単に調べることができる包括的なログ ファイルを確保するために、これを知りたいです。

MVC のエラー処理について理解しようとしています。私が探しているのは、エラーをキャッチし、ログに記録し、可能であれば解決し、必要に応じて他のアクションを実行し、最終的に正しいビューをユーザーに表示する集中型の方法です。

これには [HandleError] フィルターを使用できると思いますが、コントローラー/アクションにルーティングする方法がわかりません。私が見る唯一のオプションは、それを直接ビューに向けることです。

Javaでの自動エラー報告システムを知っている人はいますか? クライアントサーバーにインストールされるサーバー製品があります。私たちのサーバーはエラーの詳細をサーバーの 1 つに電話をかけ、バグ トラッカーにバグを入力するという考えです。できれば、これは http 経由で行われます。すべての例外で発生するわけではありません。より深刻な例外と、他の方法で処理されない例外だけです。

私は自分自身を転がすことを避けようとしています。自分たちで例外をキャッチしますが、このシステムが例外ハンドラーとバグトラッカーの間で可能な限り多くのことを処理してくれることを願っています。

私は現在、社内で作成された多くのカスタム アプリケーションを扱う会社で働いています。現在、多くのことについて基準がありません。このプログラムで発生したエラーを記録/追跡する方法を実装したいと思います (ほとんどは asp.net です)。

現在、Application Error メソッドの Global.asax でこれを処理することを考えています。まず、情報をエラー ログ/追跡データベースに保存しようとします。それが失敗した場合は、電子メールを送信してみてください。

エラー メッセージやその他のアプリケーション変数 (ページ、ユーザー名など) から取得するのに最も役立つ情報はどれですか。

現在、2 つのテーブルを使用することを考えています。1 つは一般的なエラーとアプリケーションの情報を取得するためのもので、もう 1 つは例外情報を保持するためのものです。これは、1 つのアプリケーション レベルの例外から発生する内部例外を処理するための 1 対多の関係になります。

私は多くの詳細を見逃していると確信しており、この問題を処理するためのあなたの戦略を聞きたいと思っています.