Differences between error methods in log4j 1.x










-2















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.










share|improve this question



















  • 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 than t.getMessage(). It's the difference between java.lang.NullPointerException: null vs just null.

    – Thilo
    Nov 14 '18 at 12:19















-2















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.










share|improve this question



















  • 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 than t.getMessage(). It's the difference between java.lang.NullPointerException: null vs just null.

    – Thilo
    Nov 14 '18 at 12:19













-2












-2








-2








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.










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 than t.getMessage(). It's the difference between java.lang.NullPointerException: null vs just null.

    – Thilo
    Nov 14 '18 at 12:19












  • 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 than t.getMessage(). It's the difference between java.lang.NullPointerException: null vs just null.

    – 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












1 Answer
1






active

oldest

votes


















1














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).






share|improve this answer
























    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
    );



    );













    draft saved

    draft discarded


















    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









    1














    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).






    share|improve this answer





























      1














      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).






      share|improve this answer



























        1












        1








        1







        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).






        share|improve this answer















        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).







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 14 '18 at 12:26

























        answered Nov 14 '18 at 12:21









        ThiloThilo

        195k78420575




        195k78420575





























            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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







            這個網誌中的熱門文章

            How to read a connectionString WITH PROVIDER in .NET Core?

            In R, how to develop a multiplot heatmap.2 figure showing key labels successfully

            Museum of Modern and Contemporary Art of Trento and Rovereto