Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
I also use mostly one level debug.
I prefer different files then different levels. It’s easier to open and follow 100mb file then 1gb file on server if something got wrong.
Forgot to mention I got named each logger in each file differently if that’s what level is I got gazilion of it.
Here are the log entry types/levels I use:
You mean to get a degree we must use all kinds of debug levels? Which rule on earth states so?
Use what you need to, not everything.
so why do you use logger at all? Why not just print it all ro stdout/stderr? You kind of beat the very core purpose of logger.
@leduyquang753 yes, one should know tools have their purpose.
If you only need to drive to work, purchasing a tank might be a slight overkill.
If you just need some messages printed out, using logger might be a slight overkill.
@leduyquang753 Mate, what and how you use log levels is part of my rant.
The degree comment was more along the lines of "you should at least know what other levels are" if you have a degree in IT. If you left uni without learning that you should ask them for a refund.
My colleague actually though that logger. debug() is only for Debug builds and that it's "removed" from Release builds, so he thought it's safe to log passwords and keys 😒
@LordPeeve 😊 Thanks!
I'm writing a nested logging library that implements these types (plus a bunch of other features) in my total lack of free time. I may post a link here when it's ready for release, but I don't want to tie my devRant identity to my real one, so I might not.
But to answer your question:
"Meta" is for log entries from/about the logger itself. Changes in log-level, delayed file writes, disk/access errors, etc. Useful when the log output also goes to stdout/err.
nam178874678d@leduyquang753 For toys project yes, do whatever you want.
For serious project, this is the minimum:
- Debug: Use for non-errors that can be turned off in production.
- Info: Use for non-errors, this should be leave on in production.
- Warn: Use for errors that can be safely ignored.
- Error: Use for errors that must NOT be ignored.
- FATAL: Use when the application crash.
1. You can set monitoring (count the INFOs and WARNs) to measure the traffic, success and failure rate.
2. You can set alerts (count the Errors and Fatal), let the system notify you directly on the phone as soon as a problem occurs.
3. You can turn on debugging and turn them off when no longer needed.
@Kruzifix Fatal is for anything that the program cannot recover from, or that prevents it from working and forces a crash/termination. (It's not possible to log all fatal errors, of course.)
Failed autoupdate that kills the install (literal fatal error!), corrupt database, internal inconsistencies, runtime exceptions, missing files, etc.
@netikras I use it cause it provides me functionality to save to file, split files based on logger instance and report errors as ERROR level.
I log to many files cause I have many systems I need to communicate with and some requests I want to backup for further processing.
My structure gives me instant access to issues, isn’t it purpose of logging?
@LordPeeve Your rant didn't say "he knows nothing other than DEBUG" but rather "he only needs DEBUG".
@nam17887 I didn't say you should know only what you need - learning new stuff has never been not interesting. The log levels, as weel as everything else, people may know about, but some people will need to use them, others simply don't, and you have no reason to accuse them for not using unless required.
Hazarth1138dLogging takes I/O and costs performance and on top makes logs more useful but harder to read. The whole point of levels (at least in my opinion atleast) is to be able to switch them around when something is wrong.. production needs to still log errors and warnings, but doesnt need debugging help. But a developer will be happy to see those, so instead of deleting them when you dont need them, you keep them in and just turn them off for production. And then theres commonly also TRACE which should be the most hardcore log that takes you almost step by step through important functions and subfunctions. Thats for when the debug log just seems all fine but something is wrong and you cant track it (perhaps you dont have access to the source code and a debugger but need to track a bug down)... Thats how I use them
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job
sladuled13Fuckin hell!! Code works everywhere except at one client. Ok, I check logs & see something missing.. I go che...
DarekGreenly3Quantum bugs. Code starts working when the only thing you do is examine it with console logs.
UltimateZero2I had a weird dream last night where people communicated by using log statements. Like if I wanted to say som...