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 ??
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).
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.
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.
Jeroen T Wenting
Joined: Apr 21, 2006
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.
Since the instructions does not require the logging system, if we implemented it, is it a overkill?
Jeroen T Wenting
Joined: Apr 21, 2006
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).