This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
I do not use stack trace or looging in my assignment. I do not think URLBird users will understand stack traces, and logging is not something that was required on my assignment. I just try display a relavent error message to the end user.
Joined: Nov 13, 2008
I decided to use a little printStackTrace() at certain points to allow administrators to look for errors.
But all the user that uses the application will see is a popup like "a technical error has occurred".
Sometimes logging is useful, as example when the software is in production mode. My opinion is, at the time of development, printStacktrace is extremely helpful as you can see the error. but in the production mode, it is very helpful with logging.
I have used logging API in my application for debugging. I have left the logging code in all my classes, so when enhancements are made it can be reused. I have turned off all logging before submitting the project. I decided not to log any exception using the logging API, because it could be logging is turned completely off. So an exception is sent to standard error output.
And of course user will see a human-readible (and understandable) message.
I am working through the scjd book and I am currently interested in the logging functionality:
1/ The code example in the book uses different logger's in the application classes. Why is this?. My understanding would be to use the same logger through the whole application and write everything to that.
2/ I will write my logs to a text.log using setlevel(leve.all) and switch off when the application works. Is this good practice from a tech support / audit trail point of view?
1/ You could write everything to one file, but you can write to seperate loggers (like in the book): one for db, one for gui,... The main advantage is that you can change settings per logger, so your logger for db could use another logging level than the one for the gui. I used also different loggers per package.
2/ I did exactly the same. Use the logger for debugging purposes and disabled all the logging when submitting the assignment (of course I have documented this decision too). I didn't use a file, but just the console, because where are you gonna put the file? And what if that directory is write-protected for example?
i am currently fine-tuning my assignment and i must say the logging is really good for debugging purposes. I log relevant details to a file. And i hv a util package where i am putting all my log output. With this, whatever goes on from start of application to finish can be traced.