This excerpt is from the following awesome post.
ERROR – something terribly wrong had happened, that must be
investigated immediately. No system can tolerate items logged on this
level. Example: NPE, database unavailable, mission critical use case
cannot be continued.
WARN – the process might be continued, but take extra caution.
Actually I always wanted to have two levels here: one for obvious
problems where work-around exists (for example: “Current data
unavailable, using cached values”) and second (name it: ATTENTION) for
potential problems and suggestions. Example: “Application running in
development mode” or “Administration console is not secured with a
password”. The application can tolerate warning messages, but they
should always be justified and examined.
INFO – Important business process has finished. In ideal world,
administrator or advanced user should be able to understand INFO
messages and quickly find out what the application is doing. For
example if an application is all about booking airplane tickets, there
should be only one INFO statement per each ticket saying “[Who] booked
ticket from [Where] to [Where]“. Other definition of INFO message:
each action that changes the state of the application significantly
(database update, external system request).
DEBUG – Developers stuff. I will discuss later what sort of
information deserves to be logged.
TRACE – Very detailed information, intended only for development. You
might keep trace messages for a short period of time after deployment
on production environment, but treat these log statements as
temporary, that should or might be turned-off eventually. The
distinction between DEBUG and TRACE is the most difficult, but if you
put logging statement and remove it af
answered 2013-04-30T16:02:37.173