Re: When to log? (best practices and localization)

On Aug 31, 1:16 pm, Karsten Wutzke <kwut...@xxxxxx> wrote:
So the short answer would probably be
to use a logging tool whenever you can over any System.out or
System.err prints, but this seems to include (too) much overhead. Is
it?

There is one reason to log: To provide information.

There are three main categories for which people want to have
information:

- To diagnose problems
- To create statistics (performance, utilization, etc.)
- To charge for a service

The details of what information has to be provided needs to be
negotiated with all stakeholders. One stakeholder, but far from being
the only one, is the programmer.

The amount of information to provide needs to be balanced against
required resources, e.g. disk space to store the data, but also
simplicity to analyze and find interesting data in a log in a
reasonable time.

I'm rather vague on what I really want to ask here, I simply don't
know when to use a logging tool and when System prints are "enough".

Use a logging framework in any serious application.

log.error("Failed to get IP addresses from " + strHostName + "!",
e);

Such a message, if this is the only message about the problem, lacks
important details:

- Why was the application attempting to do the operation which then
failed? What was the purpose of trying to do this from an application
point of view?

E.g. the difference between "could not connect to host 192.168.0.1,
error abc" and "could not connect to measurement station at
192.168.0.1, error abc, to fetch latest measurement data for xyz"

- What application function does no longer work because of this
problem? What information might not be processed or even lost because
of this?

E.g. "measurement data from 192.168.0.1 currently out of date,
analysis process ... suspended for 192.168.0.1".

- Can/will the application recover from this failure by its own? And
under which conditions?

E.g. "will attempt four more times to fetch missing data".

Is it better to log here or should the caller of the method log
depending on what is returned?

In case you need to provide context (see above) you often need to log
on a much higher level.

This would of course hide the exception
which was thrown. What is the best practice if one can say at all?

No, let the exception propagate upwards, possibly adding information
to the exception at each level about the context in which the error
happened. Let the one (high up) hierarchy level that makes the
decision how (if at all) to continue despite the error also write the
log info (including the decision how to continue).

Do not let lower-level routines make predictions or guesses (write
messages) about the consequences of a problem on their level.

This strategy is valid for all the information categories. E.g. you
typically don't want to log every byte going over the network. Instead
you often want to have it per connection, and often you want to know
the type/purpose of the connection, too.

Is it common to use localized messages for the logs (the app IS
localized)?

I have never come across a requirement to localize log messages.
Please note that log messages are conceptually different from error
messages for end users. Log messages are for professionals.

What is the best way to implement a log window? Find the log file and
display it in a text component?

Leave the analysis and analysis tools to the admins dealing with the
application. They usually have their preferred tools.

If you provide tools, e.g. for statistical analysis, make them first
of all command-line, scriptable tools. GUIs are only an add-on.

PS: What is the more predominant term, internationalization (I18n) or
localization (L10n)?

They mean different things. The terms are related but not
interchangeable.

Internationalization means to prepare an application for localization.
Localization means doing the adaptation of a prepared application for
one or more particular locales.

Very much simplified I18N is the job of the programmer and L10N is the
job of the translator.

.