• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Exception Logging & printStackTrace()

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have a question regarding exception handling on my server side and client side.
When catching exceptions, is it best to log exceptions to a special log file on the server side and display user-friendly errors to the user (using JOptionPane.showMessageDialog) on the client side.

Should printStackTrace() be used in all the catch blocks of exceptions ??
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sham,

Personally I am not a fan of printStackTrace() as it relies on several things
  • The user must have a console window open to see the stack trace.


  • This may not be a valid assumption - by default Microsoft Windows assumes that a jar file should be executed by javaw.exe, in which case you would not see a console window.

    Likewise on a server you may not have any console window, and may not have anyone checking it even if it does exist. (Forgetting for the moment that our server requires a GUI :roll: ).

  • The user is OK with messages appearing in the command window.


  • Most users I know have major problems with any message appearing on the console. Having a stack trace just looks ugly and scares many end users.

  • The user knows what to do with the stack trace.


  • For you to debug the problem, you need to see the stack trace. If the user doesnt know how to copy the stack trace from your command window, you are stuck. Or if they close the application you are stuck. And so on...
    Having a log file is much much simpler. You can log as much (or as little) as you like, and if the user reports a problem you can ask them to send you the entire log file.

    Having said all that, though, you might want to have all the logging within your application, but having it defaulting to being switched off before submission so that you are not creating log files all over the place (and probably make a note of the fact that you are deliberately doing this in your design decisions document).

    Regards, Andrew
     
    Ranch Hand
    Posts: 1847
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    What I do is use JSE logging to display messages. The user can (let's assume he has the knowledge to do so or his sysadmins do which I think is valid else Sun wouldn't have included the system right?) set that to display more or less as he desires using a standard system provided by Sun and documented in the JRE/JDK documentation.

    In extreme cases that will log stacktraces, but only if specific logging levels are turned on which are finer than is the case with the default settings (thus enabling them only with explicit user action).

    The advantages of JSE logging go further of course, as it can be easily diverted to a file by either diverting the console output or by setting the appropriate logging options in a standardised way.
    The output itself is also standardised of course.
     
    Ranch Hand
    Posts: 918
    IntelliJ IDE Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi guys,

    Do you split the the loggin file in two like server / client ?

    Regards M
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Mihai,

    Yes or no - it depends

    There are times when having a central logging system is very valuable (sometimes even mandatory). In other cases it just complicates matters and increases network traffic for no good reason. Part of being a developer is to recognize that such issues exist and hopefully come up with a proposal.

    In this particular case I personally would probably go with seperate log files - one for the server, and one for each client.

    Regards, Andrew
     
    Jeroen T Wenting
    Ranch Hand
    Posts: 1847
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'd go for a separate log per JVM (that's in part why I use the standard logging ) . If the client chooses to run client and server in the same JVM, that's their responsibility.
     
    Ranch Hand
    Posts: 52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi,

    Since the instructions does not require the logging system, if we implemented it, is it a overkill?
     
    Jeroen T Wenting
    Ranch Hand
    Posts: 1847
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    You will need some logging for debugging purposes during development.
    If you use the standard logging API you can just turn down the logging settings in the JVM config to get rid of that and not change your code (with possible consequences of that).
     
    reply
      Bookmark Topic Watch Topic
    • New Topic