java：プロダクション環境でのprintStackTraceの使用

Question

私はプロダクションサーバーの下にWebアプリケーションをデプロイします。 実稼働環境のキャッチブロックの下にprintStackTraceを含めることはできますか？ （キャッチブロックのログがエラーの正確な原因を知るのに役立たないため） キャッチブロックの下にprintStackTraceを持っているのが分かりますか？

たとえば、私は意図的に無効なポート番号を設定し、printStackTrace（）は私にこの情報を与えます。

のprintStackTrace（）：

java.lang.IllegalArgumentException: port out of range:80800 
     at java.net.InetSocketAddress.<init>(InetSocketAddress.java:118) 
     at sun.net.NetworkClient.doConnect(NetworkClient.java:163) 
     at sun.net.www.http.HttpClient.openServer(HttpClient.java:395) 
     at sun.net.www.http.HttpClient.openServer(HttpClient.java:530) 
     at sun.net.www.http.HttpClient.<init>(HttpClient.java:234) 
     at sun.net.www.http.HttpClient.New(HttpClient.java:307) 
     at sun.net.www.http.HttpClient.New(HttpClient.java:324) 
     at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:970) 
     at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911) 
     at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:836) 
     at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1014) 
     at com.tata.util.XmlClient.execute(HttpXmlClient.java:83) 

ログのスタイル：

、ログが（私はApacheのコモンズにログインするためのログメカニズムを使用しています）

Log.write("**EXCEPTION INSIDE execute " + e, Log.INFO); 

06/Jan/2012 16:25:55 - main:http-8080-2 <> <60990020>**EXCEPTION INSIDE execute java.lang.IllegalArgumentException: port out of range:80800 

これを与えるので、

catchブロックの下にprintStackTraceを置くことが許容されるかどうか教えてください。

Answer 1

ログにもスタックトレースが表示されますが、正しく使用されていません。試してみてください：あなたがLog.write("**EXCEPTION INSIDE execute " + e, Log.INFO);を行うと、文字列結合演算子として使用するプラス記号が実際に例外オブジェクトを取得するには決して変更を取得していない、"**EXCEPTION INSIDE execute "文字列にそれを電子オブジェクトのtoString()メソッドを呼び出して、追加します

log.error(Object message, Throwable t); 

スタックトレースです。あなたの人生のアプリでスタックトレースを持つ

http://commons.apache.org/logging/guide.html#Loggingメッセージ

Answer 2

は確かに悪いです。

printStackTraceのポップアップを作成して、特定のデバッグフラグがアクティブな場合は表示しないでください（これがjavaでどのように行われているかはわかりません）。

通常、すべての例外は、処理する必要があるところまでバブルアップされます。接続エラーは、アプリに表示したい情報である可能性があります。そのため、フロントエンド（ポップアップなど）で処理する必要があります。

Andrei Bodnarescuが正しいです、あなたのロガーを修正することも同様です。

Answer 3

このようにすれば、ロギングの最初のアプローチであり、明らかに問題が発生したときの解決に役立ちます。しかし、log4jやcommons loggerなどのロギングライブラリを使用してアプリケーションを設定し、余分なデータ（DBクエリ、操作結果など）を出力することで、スタックトレースと並んでいくつかのものを取得することができます。フォーマット。

また、トレースを含むコンテナ/ Webサーバーログを使用すると、クライアントで疑問が生じることがありますが、構造化されたアプリケーションログを使用すると、より穏やかな状態に保たれます。知覚の問題。

Answer 4

はい、実稼働環境での例外のスタックトレースを印刷することは可能です。 必要に応じて、例外処理を上方にスローすることができます。