Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

include logging?

 
BillLeighton
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand the value of using extensive logging during the development process, but would it be bad to leave logging code (even SEVERE logging) in the final project? I understand the general thought is not to leave JUnit tests in the code, particularly as the submitter did not write JUnit, but the logging stuff is Sun's , and seems fair game...
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11943
212
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bill
Personally I did not have any logging at all in my application.
However, if by default, logging was turned off, and the logging was done properly, then it should be OK - it shows that you are thinking about maintainability.
By properly, I mean that you do use the different log levels ( so you don't get an all or nothing approach to logging), and maybe (if possible) you have a modular approach to logging (so you can say only turn on logging for networking for instance).
The problem of course, is that if you get it wrong, then the examiner may look at what you have written and decide to take a mark off in the "general considerations" section.
Regards, Andrew
 
Damian Ryan
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I did exactly what you suggest, Bill, and left all my logging code (Java 1.4 logging API) in my submitted code.
I used system properties to allow individual packages to have their logging switched on to an appropriate level, the default being no logging if no property was supplied with the command line (as would be the case when the assessor runs the code).
For example:

would run a main class called suncertify.client.Client, with logging level set to "INFO" (all INFO and above logged) for any classes in the suncertify.db package.
And
would do the same, but because no logging properties has been set, all packages would have their log level set to "NONE".
This required the help of a very simple (a few lines) helper class to read system properties and set up log levels appropriately.
I found the logging very helpful during development and testing, especially when ensuring threadsafe concurrent access to the database, but I would echo what Andrew said about making sure you do it right if you are going to use it. But it's really not that difficult, so be brave!
BTW, I didn't lose any marks for my approach.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree wholeheartedly: leave the logging in, but with a caveat. Don't log to a file. Why not? Mostly because it introduces the risk that something might go wrong at the IO level, thus causing your project undue burden. Log away, IMO, but only to the default err.
M
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you use java.util.logging, then logging level and handlers can be controlled entirely by the logging.properties file. By default this sets up a single console handler at level INFO. For your own debugging you can certainly add logging to a file at whatever level you want by changing your logging.properties file - this won't affect logging on the test examiners' machines, because they will have their own logging.properties. If they have chosen to set up logging to a file, that's their business, not our problem. By default though they will just see console logging at INFO level.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic