Differences between error methods in log4j 1.x
In the logging part of the project I working for, I try to optimize the error messages that are shown in log management. Logging error messages is coded like this:
String errorMessage =" Problem with server "+"n"+t.getMessage();
_logger.fatal(errorMessage);
Where t is a Throwable object and _logger is a Logger object, which is related to the log4j framework.
What I wonder is, what changes if I use _logger.fatal(errorMessage, t);
instead of _logger.fatal(errorMessage);
? If there is a major difference between them, Which one will be better to use?
Edit: I've just realised I copied "fatal" example instead of "error". However my question is same for fatal, too.
java logging log4j
add a comment |
In the logging part of the project I working for, I try to optimize the error messages that are shown in log management. Logging error messages is coded like this:
String errorMessage =" Problem with server "+"n"+t.getMessage();
_logger.fatal(errorMessage);
Where t is a Throwable object and _logger is a Logger object, which is related to the log4j framework.
What I wonder is, what changes if I use _logger.fatal(errorMessage, t);
instead of _logger.fatal(errorMessage);
? If there is a major difference between them, Which one will be better to use?
Edit: I've just realised I copied "fatal" example instead of "error". However my question is same for fatal, too.
java logging log4j
3
if you use_logger.fatal(errorMessage, t);
you see the stacktrace otherwise only the message
– Jens
Nov 14 '18 at 12:17
Which one will be better to use: it depends on ...
– Jens
Nov 14 '18 at 12:18
If you really don't want the stack trace,t.toString()
may also be more informative thant.getMessage()
. It's the difference betweenjava.lang.NullPointerException: null
vs justnull
.
– Thilo
Nov 14 '18 at 12:19
add a comment |
In the logging part of the project I working for, I try to optimize the error messages that are shown in log management. Logging error messages is coded like this:
String errorMessage =" Problem with server "+"n"+t.getMessage();
_logger.fatal(errorMessage);
Where t is a Throwable object and _logger is a Logger object, which is related to the log4j framework.
What I wonder is, what changes if I use _logger.fatal(errorMessage, t);
instead of _logger.fatal(errorMessage);
? If there is a major difference between them, Which one will be better to use?
Edit: I've just realised I copied "fatal" example instead of "error". However my question is same for fatal, too.
java logging log4j
In the logging part of the project I working for, I try to optimize the error messages that are shown in log management. Logging error messages is coded like this:
String errorMessage =" Problem with server "+"n"+t.getMessage();
_logger.fatal(errorMessage);
Where t is a Throwable object and _logger is a Logger object, which is related to the log4j framework.
What I wonder is, what changes if I use _logger.fatal(errorMessage, t);
instead of _logger.fatal(errorMessage);
? If there is a major difference between them, Which one will be better to use?
Edit: I've just realised I copied "fatal" example instead of "error". However my question is same for fatal, too.
java logging log4j
java logging log4j
edited Nov 14 '18 at 12:35
tom1299
618
618
asked Nov 14 '18 at 12:10
Bernard Black the SecondBernard Black the Second
531214
531214
3
if you use_logger.fatal(errorMessage, t);
you see the stacktrace otherwise only the message
– Jens
Nov 14 '18 at 12:17
Which one will be better to use: it depends on ...
– Jens
Nov 14 '18 at 12:18
If you really don't want the stack trace,t.toString()
may also be more informative thant.getMessage()
. It's the difference betweenjava.lang.NullPointerException: null
vs justnull
.
– Thilo
Nov 14 '18 at 12:19
add a comment |
3
if you use_logger.fatal(errorMessage, t);
you see the stacktrace otherwise only the message
– Jens
Nov 14 '18 at 12:17
Which one will be better to use: it depends on ...
– Jens
Nov 14 '18 at 12:18
If you really don't want the stack trace,t.toString()
may also be more informative thant.getMessage()
. It's the difference betweenjava.lang.NullPointerException: null
vs justnull
.
– Thilo
Nov 14 '18 at 12:19
3
3
if you use
_logger.fatal(errorMessage, t);
you see the stacktrace otherwise only the message– Jens
Nov 14 '18 at 12:17
if you use
_logger.fatal(errorMessage, t);
you see the stacktrace otherwise only the message– Jens
Nov 14 '18 at 12:17
Which one will be better to use: it depends on ...
– Jens
Nov 14 '18 at 12:18
Which one will be better to use: it depends on ...
– Jens
Nov 14 '18 at 12:18
If you really don't want the stack trace,
t.toString()
may also be more informative than t.getMessage()
. It's the difference between java.lang.NullPointerException: null
vs just null
.– Thilo
Nov 14 '18 at 12:19
If you really don't want the stack trace,
t.toString()
may also be more informative than t.getMessage()
. It's the difference between java.lang.NullPointerException: null
vs just null
.– Thilo
Nov 14 '18 at 12:19
add a comment |
1 Answer
1
active
oldest
votes
Practically all Java logging framework (alas, we have plenty of those...) support putting a Throwable
as the last parameter.
This will result in a stack trace being logged, which can be extremely useful in diagnosing and fixing the problem.
I'd only ever not give the exception to the logger if the cause of the exception is really well established and printing the exception is just unnecessary noise. For example here:
try
int port = Integer.parseInt(input);
// do something with the port
catch (NumberFormatException e)
logger.error("'' is not a valid port number: ", input, e.toString);
Another case is when the exception is being re-thrown (and something else will eventually log it with more detail).
But not with a "Problem with server" (and at FATAL level no less). That looks like you want to get as much info as you can get.
Also note that in those cases, e.toString()
is usually better than e.getMessage()
because it also includes the name of the exception in addition to its message (which may be empty).
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53299938%2fdifferences-between-error-methods-in-log4j-1-x%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Practically all Java logging framework (alas, we have plenty of those...) support putting a Throwable
as the last parameter.
This will result in a stack trace being logged, which can be extremely useful in diagnosing and fixing the problem.
I'd only ever not give the exception to the logger if the cause of the exception is really well established and printing the exception is just unnecessary noise. For example here:
try
int port = Integer.parseInt(input);
// do something with the port
catch (NumberFormatException e)
logger.error("'' is not a valid port number: ", input, e.toString);
Another case is when the exception is being re-thrown (and something else will eventually log it with more detail).
But not with a "Problem with server" (and at FATAL level no less). That looks like you want to get as much info as you can get.
Also note that in those cases, e.toString()
is usually better than e.getMessage()
because it also includes the name of the exception in addition to its message (which may be empty).
add a comment |
Practically all Java logging framework (alas, we have plenty of those...) support putting a Throwable
as the last parameter.
This will result in a stack trace being logged, which can be extremely useful in diagnosing and fixing the problem.
I'd only ever not give the exception to the logger if the cause of the exception is really well established and printing the exception is just unnecessary noise. For example here:
try
int port = Integer.parseInt(input);
// do something with the port
catch (NumberFormatException e)
logger.error("'' is not a valid port number: ", input, e.toString);
Another case is when the exception is being re-thrown (and something else will eventually log it with more detail).
But not with a "Problem with server" (and at FATAL level no less). That looks like you want to get as much info as you can get.
Also note that in those cases, e.toString()
is usually better than e.getMessage()
because it also includes the name of the exception in addition to its message (which may be empty).
add a comment |
Practically all Java logging framework (alas, we have plenty of those...) support putting a Throwable
as the last parameter.
This will result in a stack trace being logged, which can be extremely useful in diagnosing and fixing the problem.
I'd only ever not give the exception to the logger if the cause of the exception is really well established and printing the exception is just unnecessary noise. For example here:
try
int port = Integer.parseInt(input);
// do something with the port
catch (NumberFormatException e)
logger.error("'' is not a valid port number: ", input, e.toString);
Another case is when the exception is being re-thrown (and something else will eventually log it with more detail).
But not with a "Problem with server" (and at FATAL level no less). That looks like you want to get as much info as you can get.
Also note that in those cases, e.toString()
is usually better than e.getMessage()
because it also includes the name of the exception in addition to its message (which may be empty).
Practically all Java logging framework (alas, we have plenty of those...) support putting a Throwable
as the last parameter.
This will result in a stack trace being logged, which can be extremely useful in diagnosing and fixing the problem.
I'd only ever not give the exception to the logger if the cause of the exception is really well established and printing the exception is just unnecessary noise. For example here:
try
int port = Integer.parseInt(input);
// do something with the port
catch (NumberFormatException e)
logger.error("'' is not a valid port number: ", input, e.toString);
Another case is when the exception is being re-thrown (and something else will eventually log it with more detail).
But not with a "Problem with server" (and at FATAL level no less). That looks like you want to get as much info as you can get.
Also note that in those cases, e.toString()
is usually better than e.getMessage()
because it also includes the name of the exception in addition to its message (which may be empty).
edited Nov 14 '18 at 12:26
answered Nov 14 '18 at 12:21
ThiloThilo
195k78420575
195k78420575
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53299938%2fdifferences-between-error-methods-in-log4j-1-x%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
if you use
_logger.fatal(errorMessage, t);
you see the stacktrace otherwise only the message– Jens
Nov 14 '18 at 12:17
Which one will be better to use: it depends on ...
– Jens
Nov 14 '18 at 12:18
If you really don't want the stack trace,
t.toString()
may also be more informative thant.getMessage()
. It's the difference betweenjava.lang.NullPointerException: null
vs justnull
.– Thilo
Nov 14 '18 at 12:19