log level:scope detailed description
Added by Mario Diethelm 9 months ago
Hello,
where can I find a "log level:scope" detailed description?
Thanks.
Replies (4)
RE: log level:scope detailed description - Added by Christian Meyer 9 months ago
Had a similar Question a while back
https://redmine.emweb.be/boards/2/topics/18076?r=18080#message-18080
Hope this is detailed enough there?
RE: log level:scope detailed description - Added by Mario Diethelm 9 months ago
Understood. Thanks a lot.
Talking specifically about Wt library I have identified some obvious "info:scope" through applications log: info:WebRequest, info:WebController, info:WEnvironment, info:Wt and info:wthttp. Do you have a complete list of all level:scope combinations that the library emits ideally with an explanation of when and why those messages are issued?
Thanks again. Best regards
RE: log level:scope detailed description - Added by Christian Meyer 9 months ago
I do not =)
I am happy to use log:scope for debug messages that I can configure the detail of on the fly and just forget about them when it works.
And then still have them, when I want to upgrade stuff later.
RE: log level:scope detailed description - Added by Matthias Van Ceulebroeck 8 months ago
Hello Mario,
my apologies for the later reply.
Generally speaking internally Wt will use LOG_ERROR
, LOG_WARN
, LOG_SECURE
, LOG_INFO
, and LOG_DEBUG
. Where often the scope is the name of the main class of the file. The debug
level is mostly very verbose, and gives good output during development. It'll often point out what is happening on a low level, and allow developers to trace specific issues. The info
level is fairly similar to it, but often less verbose. It will still provide more information on what functionality is being executed, what it results in, or what effects it has, but more succinct than debug
.
All other levels (being error
, warn
, and secure
) are considered more "necessary". These often result in log entries where the application got in a weirder state or things are happening where they shouldn't (think of bad input, bad handling, errors occurring, ...).
All of this is with a grain of salt, as deciding what is logged where can often be tricky, and will depend on developer interpretation.
I hope this somewhat answers your question.
Best,
Matthias