Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: Choosing a log level

by Discipulus (Canon)
on Mar 29, 2017 at 08:03 UTC ( #1186326=note: print w/replies, xml ) Need Help??

in reply to Choosing a log level


while my opinion might not be so relevant, i think that too many levels of logging make the decision to assign a particular event to a precise log level too discretional and possibly smoky and confusing particulary when you need to add code later and the perception of what level apply to an event can be slightly changed.

By other hand it always depends on the nature of the application: I think, about logging, you must think about the consumer of information to decide correctly. Normally there are just two consumers: the user and the programmer. Again normally the programmer want to be aware of user problems, but is not always true: infact you can have, let's say, a huge file upload application where you want/must tell between user_error and client_error and server_error as you can have another application where you want a supervisor_info distinct from a general info level.

In most complex situations you can have some consumers of information that overlap so you have granulary defined log levels that group togheter under some circumstance: $usrlog = qw(ERROR USER_INFO); $supervisorlog = (SUPER_INFO USER_ERROR) and so on..

In such cases is better to have the possibility of manually include a log level into another. Generally DEBUG implies all other levels: you may prefere something different in some circumstance. You can build up the list of levels with the rule that if only one level is specified for, let say, user it contains all the lower ones but if you specify more of them this will be the final list: so you can have $usr_log = qw(INFO); is the same of $usr_log = qw(INFO WARN ERR FATAL); but $dev_log = qw(DEBUG ERROR FATAL DB_ERROR DB_WARN DB_FATAL); that does not contains INFO nor WARN

But in the majority of the case there are only the programmer and the user; if so i'd choose something simpler (as i'v done in my little log experiment):

FATAL user and dev must be aware that the application cannot continue +: a fundamental resource cannot be reached, authentication failure fo +r the main application, another instance of a singleton is running... + ERROR any error that does not fall in the fatal ones: user login error +s, needed but not necessary files cannot be written or read. This lev +el mixes user's errors and application ones as generally both consume +rs are interested in them WARNING unexpected behaviours that are not strictly errors as choosing + a destination folder that does not exists, a destination files that +already exists. user's warnings generally let the user to rerun some +action. application warnings are autorecoverable errors like database + connectivity impossible with the first DB but a second attempt will +be made INFO any positive feedback from the application to the end user DEBUG any positive feedback from the application to the programmer: t +he file was open, the DB is available, the datastructure taken will b +e dumped..


There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Replies are listed 'Best First'.
Re^2: Choosing a log level
by hippo (Bishop) on Mar 29, 2017 at 08:28 UTC

    Very good, thoughtful post (++). There's just one point which baffles:

    needed but not necessary files

    What should this convey? To me, "needed" pretty much implies "necessary" and vice-versa. If you could clear that up then you would have a great sequence of categories.

      well the words seem identical in their sense but what i meant was, for example, an output file that cannot be written. This might not be a fatal error: you may receive ERROR: out.txt is in use and $0 cannot lock it that is different from FATAL cannot read the configuration you supplied even if it exists

      So probably the best word is complementary instead of needed, thanks for the comment.


      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

        I was pondering on this for a few minutes, and I might describe ERROR as "locally fatal" as compared to being "globally fatal"

        The current operation is impossible, but the application as a whole can continue operating.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1186326]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (1)
As of 2023-06-03 17:53 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (16 votes). Check out past polls.