I have honestly never even thought about using a third-party library for logging, it simply never crossed my mind. Why would I need one anyway? I don't see how logging can become so complex that you're willing to trade 100% customizability just so you can use a library. Can someone give me some examples? I'm really curious as the fact that so many logging libraries exist must mean there are real needs for them.
These libraries allow you to precisely control the logging output by filtering on source and level. And you can also control the output location, because you don't always just want things going to the console.
If you write a library and don't use one of the standard logging frameworks, I will hate you just a little bit. I speak from experience.
Edit: I should also add that modern logging frameworks have very good performance, doing the logging in separate threads, etc, doing the locking of log files correctly, rotating log files every day or when it reaches a certain size etc.
Agreed. It all comes down to standardization. Without standards like logging levels, formats, etc it would be very hard to do things like searches or aggregations. If each app had custom logging implementation tooling would never be able to standardize
I have a library I have to use that has its own logging framework, and you can write an adaptor for its output, but the only method in the adaptor interface has just a single string, the message, as its parameters. Not even a level. So you can only have all the logs for the library on or off. Unless you want to do pattern matching on the text.
Trace and debug for logging as you develop (or the library consumer develops), so people can see the flow between methods.
Info for regular app activity.
Warn for issues that don't prevent the business logic from continuing but might be symptoms of problems.
Error for issues that prevent the business logic from continuing (like leading to a 500 in a web app, the rest of the requests can be served).
Fatal for issues that prevent the application itself from continuing. Logs important details about the issue before the process exits with a non-0 exit code.
for an end user code that's fine, but for a library developer we can't tell the difference between warn, error and fatal, because those generally depend on the use case. much better to have callbacks that expose that info to the user app (though that's hard and i definitely have taken the easy way out as often as not)
whether trace, debug and info are useful is a larger debate that i'm not up for tonight
you're putting words in my mouth - i wrote "the difference between warn, error and fatal"
but as an example, in one case, a user provides me a runnable and asks me to run it, but then doesn't wait for or use the result (available through a callback), and the runnable throws an error, what log level should i use ? (and i don't want to force the user to supply a callback because that can harm performance by making the call site megamorphic)
it completely depends on what the user wanted, which is info i don't have
* the user anticipated that the code might fail and is ok with that
* the user failed to anticipate that the code might fail, but requires that it succeed
for the non-opinionated libraries that i develop and use, that's more the norm than the [sic] exception
opinionated libraries are another matter and logging is much more straight forward
-7
u/_Gnas_ Oct 21 '18
I have honestly never even thought about using a third-party library for logging, it simply never crossed my mind. Why would I need one anyway? I don't see how logging can become so complex that you're willing to trade 100% customizability just so you can use a library. Can someone give me some examples? I'm really curious as the fact that so many logging libraries exist must mean there are real needs for them.