File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Doubt in Andrew's book Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Doubt in Andrew Watch "Doubt in Andrew New topic

Doubt in Andrew's book

Renu Radhika
Ranch Hand

Joined: Oct 21, 2005
Posts: 243
In chapter 5 page 123 it says "If we had created our own specialized log message,we would probably have to remove it and replace it with the standard log messages"What does this mean?I didnt get it.Can somebody help me with this?
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11776

Hi Renu

When writing our example code we decided to always use the entering() and exiting() methods at the start and end of the methods being logged.

However in the case of logging within a getter or setter method there is little value in logging both the entrance and exit from the method since there is no functionality between the two log messages. But if we have decided on a standard of logging all entering and exiting messages then we cannot really leave out one or the other - if we do not log the fact that we are exiting, then the log will be confusing: it will appear that we have never left all the getter methods. Likewise if we left out the entering messages, looking at the log you would see a lot of exiting messages from methods without it being obvious that we entered those methods.

We could, of course, have a different style of log message for getters and setters - for example we could use the finer() log level within getters and setters, while still using the entering() and exiting() methods for all of our methods that do more work.

Unfortunately this could be confusing for anyone reading the code afterwards - they would have to understand why we are using different Logger APIs in our code.

Another option would be to create our own log messages (possibly in our own class that extends from the Logger class). If we had our own "enteringAndExiting()" method, then it would fit in well with the other methods in the DVD class - for those methods that have business logic, you would call the "entering()" log API and then (eventually) the "exiting()" log API. For the getters and setters you would just call the "enteringAndExiting()" log API (that we created). This should make sense to anyone reading the code, and to anyone reading the log files.

This has the disadvantage that we now have a specialized log class and methods, and should we ever need to modify the getter or setter to do more work, then we would have to pull out our specialized method and revert to calls to the standard logging APIs. Whereas by having the redundant entering() and exiting() calls we are ready for any modifications in the future and we are using standard APIs.

Note: As mentioned at the end of page 123, the idea of logging (or unit testing) getters and setters is overkill.

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Renu Radhika
Ranch Hand

Joined: Oct 21, 2005
Posts: 243
Thanks Andre.Its clear now.
I agree. Here's the link:
subject: Doubt in Andrew's book
It's not a secret anymore!