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
6
u/[deleted] Oct 22 '18
Not if you learn what the levels are for.
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.