We call those warnings, and it's very common to downgrade errors to warnings by wrapping an exception and printing the trace as you would an exception.

▲

makeitdouble 19 hours ago | parent | next [-]

Warning logs are usually polluted with stuff nobody wants to fix but try to wash their hands off with a log. Like deprecated calls or error logs that got demoted because it didn't matter in practice.

Anything that has a measurable impact on production should be logged above that, except if your system ignores log levels in the first place, but that's another can of worms.

▲

kgklxksnrb 20 hours ago | parent | prev [-]

Logging warnings are cowardly, you just push the decision to the log consumer to decide if the error should be acted on.

Warnings are just errors that no one wants to deal with.

▲

bluGill 17 hours ago | parent [-]

Warnings are for where you expect someplace else to know/log if it really is an error but it might also be normal. You might log why a file io operation failed: if the caller recovers somehow it isn't an errer, but if they can't they log an error and when investigating the warning gives the detail you need to figure it out.

▲

kgklxksnrb 11 hours ago | parent [-]

Who proactively investigates warnings?

	▲	bluGill 10 hours ago \| parent [-]
		statistacs are someimes run and the most common investigated (normally shut up the noise) mostly though when you are on a known problem warnings should be a useful filter to find where in the logs the problem might have started, then you use that timestamp to find info logs in the same area