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.
