Re: Additional logging questions
On 2/27/2012 1:13 AM, Lew wrote:
Novice wrote:
Arne Vajh??j wrote:
Novice wrote:
Basically, I'm just about ready to start getting loggers for each and
every class in the project I'm working on now (with plans to do the
same in every project as I create it or return to it). But I don't
want to do too much logging either.....
You should log the information you expect potentially could be
useful when troubleshooting a problem.
This requires that you think like a useful person, not a computer
programmer.
When you're troubleshooting a log, you don't have code in front of you.
You have what the log tells you. It had better God-damned tell you what
you need, because you wouldn't be looking if someone weren't breathing
down your neck. No fancy "***********************=============" strings.
Logs are dense, multi-mega- or gigabyte beasts of tightly printed strings.
Ops personnel read logs. Ops personnel think programmers are children. I
had an ops mentor who told me, "We love getting the programmers from
[the development location] here for six months. They go back to coding
_changed_!"
Warning and above may be ops relevant, but the lower levels and
that is typical the majority of log messages are for developers.
You pick appropriate logging levels. Here's my log4j idiom:
public void loadResource()
{
logger.debug("");
final BufferedReader reader;
try
{
reader = new BufferedReader(new InputStreamReader(getClass()
.getResourceAsStream("/config/configuration.txt")));
}
catch(IOException exc)
{
String msg = "Cannot open configuration. "+ exc.getLocalizedMessage();
logger.error(msg, exc);
throw new IllegalStateException(msg, exc);
}
assert reader != null;
try
{
// read the Reader, etc.
}
catch(IOException exc)
{
String msg = "Cannot read configuration. "+ exc.getLocalizedMessage();
logger.error(msg, exc);
throw new IllegalStateException(msg, exc);
}
finally
{
try
{
reader.close();
}
catch(IOException exc)
{
String msg = "Cannot close configuration. "
+ exc.getLocalizedMessage();
logger.warn(msg, exc);
}
}
}
Note the multiple uses of 'logger' (an instance member) in that method.
Why do you combine English with local language?
But please add a toString method in your data class, so
when the class with real login in that uses the data class
can log it and you get something useful in the log about the
data.
Sorry, I'm not following you.
Are you saying that the toString() method needs to be there to turn
things like references into meaningful information? I know that a
reference to something like a JFrame is not going to be very meaningful
and would rather display the name given the JFrame via setName(). Or are
you saying something quite different?
'toString()' should always give a useful way to identify the specific
instance.
It should depend on (and usually only on) the same fields used to drive
'hashCode()' and 'equals()' and if supported, 'compareTo()' (which
should always be consistent with each other).
I would usually expect more fields than the identity fields
to be useful.
Arne