printStackTrace（）;は避けてください。代わりにロガー呼び出しを使用してください

私のアプリケーションでは、PMDを介してコードを実行しています。次のメッセージが表示されます。

• printStackTrace（）;は避けてください。代わりにロガー呼び出しを使用してください。

どういう意味ですか？

つまり、次のようなロギングフレームワークを使用する必要があります ログバック または log4j 例外を直接出力する代わりに：

e.printStackTrace();

このフレームワークのAPIを使用してログに記録する必要があります。

log.error("Ops!", e);

ロギングフレームワークは、多くの柔軟性を提供します。たとえば、コンソールにログを記録するかファイルにログを記録するかを選択できます。または、一部の環境でメッセージが関連しなくなった場合は、一部のメッセージをスキップできます。

printStackTrace()例外を呼び出すと、トレースが書き込まれSystem.err、他の場所にルーティング（またはフィルタリング）するのが困難になります。これを行う代わりに、ロギングフレームワーク（またはApache Commons Loggingなどの複数のロギングフレームワークのラッパー）を使用し、そのフレームワークを使用して例外をログに記録することをお勧めします（例logger.error("some exception message", e)）。

これを行うと、次のことが可能になります。

• ログステートメントを一度に別の場所（コンソールとファイルなど）に書き込みます
• 重大度（エラー、警告、情報、デバッグなど）と発信元（通常はパッケージまたはクラスベース）でログステートメントをフィルタリングします
• コードを変更せずにログ形式に影響を与える
• 等

本番品質プログラムは、エラーやその他の診断を報告するために、多くの代替ログ（log4j、logback、java.util.loggingなど）の1つを使用する必要があります。これにはいくつかの利点があります。

• ログメッセージは設定可能な場所に送られます。
• エンドユーザーは、ログを構成するように構成しない限り、メッセージを表示しません。
• さまざまなロガーやログレベルなどを使用して、記録されるログの量を制御できます。
• さまざまなアペンダー形式を使用して、ロギングの外観を制御できます。
• ロギング出力をより大きなモニタリング/ロギングフレームワークに簡単にプラグインできます。
• 上記のすべては、コードを変更せずに実行できます。つまり、デプロイされたアプリケーションのロギング設定ファイルを編集します。

対照的に、printStackTraceを使用するだけの場合、デプロイヤー/エンドユーザーはほとんど制御できず、不適切な状況ではログメッセージが失われたりエンドユーザーに表示されたりする可能性があります。（そして、ランダムなスタックトレースほど臆病なユーザーを怖がらせるものはありません。）

Simpleでは、e.printStackTrace（）はスタックトレースを標準エラーに出力するだけなので、お勧めできません。このため、この出力の行き先を実際に制御することはできません。

ほとんどすべてのロギングフレームワークは、スロー可能なオブジェクトをメッセージと一緒に渡すことができるメソッドを提供します。お気に入り：

public trace(Marker marker, String msg, Throwable t);

スロー可能なオブジェクトのスタックトレースを出力します。

会社のコンセプトからお話しましょう。ログは柔軟なレベルを提供します（logger.infoとlogger.debugの違いを参照）。QA、開発者、ビジネスマンなど、さまざまな人々がさまざまなレベルを見たいと考えています。ただし、e.printStackTrace（）はすべてを出力します。また、このメソッドが安らかに呼び出される場合のように、この同じエラーが数回出力される場合があります。次に、同じエラーリマインダーを受け取るため、社内のDevopsまたはTech-Opsの人々は頭がおかしいかもしれません。より良い代替品になると思います。log.error("errors happend in XXX", e) これにより、e.printStackTrace（）よりも読みやすい情報全体が出力されます。

主な理由は、Proguardがログ呼び出しを本番環境から削除することです。StackTraceをログに記録または印刷することで、たとえばLogcat Readerアプリケーションによって、Androidフォン内でそれら（スタックトレースまたはログ内の情報）を確認できるためです。そのため、セキュリティにとっては悪い習慣です。また、本番環境ではアクセスしません。本番環境から削除することをお勧めします。ProGuardはstackTraceではなくすべてのLog呼び出しを削除するため、Log in catchブロックを使用して、ProguardによってProductionから削除することをお勧めします。