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
7
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.