[TYPO3-v4] Harmonizing severity levels

Steffen Müller typo3 at t3node.com
Fri Nov 5 11:13:54 CET 2010


Hi.

On 05.11.2010 09:38 François Suter wrote:
> I would quite like to have your opinion on the issue. Do you think it's
> worth the effort? What should be done exactly? It's of course possible
> to adjust all t3lib_div::devLog calls in the Core, but what about
> extensions?

My opinion is that we should rather fix the severities in
(flash-)message class of core than those in devlog.

The severities in the t3lib_message class have no clear definition of
its levels. They seem arbitrary to me and without a strict linear order.

There has been put quite some knowledge and research in defining the
severities in devlog. The definition we have in devlog is:

%<--- snip

"There are five levels of severity, the higher the number, the more
serious the event:

(-1) Ok: These events indicate that everything went fine, no error
occurred (at least up to that point where the event was created). No
action needs to be taken.

(0) Info: These events are purely informational. They are normally used
for debugging purposes only and require no special action.

(1) Notice: Abnormal condition, but not blocking. Notices are meant to
raise attention. Processes have been completed, but things are not
running as smoothly as they could and the condition should be investigated.

(2) Warning: These events are used to notify significant problems.
Processes have been completed, but parts of them may be missing, wrong
or corrupted. Warnings should not be ignored and action should
definitely be taken.

(3) Error: These events signal that something went fatally wrong.
Processes were not completed and action is definitely needed.
Alternately this level may be used to point to a failed event, but in a
process where failure can be expected, e.g. a login attempt with the
wrong password.

%<--- snap

You can find it here:
http://forge.typo3.org/projects/extension-devlog/repository/entry/trunk/locallang_csh_txdevlog.xml

The concept looks coherent to me and follows a distinct logic. It aims
to be compatible with widespread logging software like syslogd.

It could also be extended with FATAL, or even CRITICAL, ALERT, EMERG on
top of ERROR.


-- 
cheers,
Steffen

TYPO3 Blog: http://www.t3node.com/
Microblog:  http://twitter.com/t3node



More information about the TYPO3-project-v4 mailing list