Log level 'error' should mean that something needs to be fixed • Hacker News Board

Re: Log level 'error' should mean that something needs to be fixed

#161

Post by layer8 » Sat, Dec 20, 2025, 9:30 PM UTC

Too wrote: post #153

MobiusHorizons wrote: post #122

Earlier quoted context omitted.

What you are proposing sounds like a nightmare to debug. The high level perspective of the operation is of course valuable for determining if an investigation is necessary, but the low level perspective in the library code is almost always where the relevant details are hiding. Not logging these details means you are in the dark about anything your abstractions are hiding from higher level code (which is usually a lo…

Simple: include those relevant details in the exceptions instead of hiding them.

It’s not that simple. First, this results in exception messages that are a concatenation of multiple levels of error escalation. These become difficult to read and have to be broken up again in reverse order.

Second, it can lose information about at what exact time and in what exact order things happened. For example, cleanup operations during stack unwinding can also produce log messages, and then it’s not clear anymore that the original error happened before those.

Even when you include a timestamp at each level, that’s often not sufficient to establish a unique ordering, unless you add some sort of unique counter.

It gets even more complicated when exceptions are escalated across thread boundaries.

Re: Log level 'error' should mean that something needs to be fixed

#162

Post by Kwpolska » Sat, Dec 20, 2025, 9:33 PM UTC

Too wrote: post #153

MobiusHorizons wrote: post #122

Earlier quoted context omitted.

What you are proposing sounds like a nightmare to debug. The high level perspective of the operation is of course valuable for determining if an investigation is necessary, but the low level perspective in the library code is almost always where the relevant details are hiding. Not logging these details means you are in the dark about anything your abstractions are hiding from higher level code (which is usually a lo…

Simple: include those relevant details in the exceptions instead of hiding them.

Not all problems cause exceptions.

Re: Log level 'error' should mean that something needs to be fixed

#163

Post by layer8 » Sat, Dec 20, 2025, 9:35 PM UTC

HendrikHensen wrote: post #149

layer8 wrote: post #76

> When implementing logging, it's important to distinguish between an error from the perspective of an individual operation and an error from the perspective of the overall program or system. Individual operations may well experience errors that are not error level log events for the overall program. You could say that an operation error is anything that prevents an operation from completing successfully, while a pro…

> Should only “top-level” code ever log an error? That can make it difficult to identify the low-level root causes of a top-level failure. Some languages (e.g. Java) include a stack trace when reporting an error, which is extremely useful when logging the error. It shows at exactly which point in the code the error was generated, and what the full call stack was to get there. It's a real shame that "modern" languages…

The point in the code is not the same information as knowing the time, or knowing the order with respect to operations performed during stack unwinding. Stacktraces are very useful, but they don’t replace lower-level logging.

Re: Log level 'error' should mean that something needs to be fixed

#164

Post by Copenjin » Sat, Dec 20, 2025, 9:36 PM UTC

rsanek wrote: post #160

If something needs to be fixed, why is it just a log? How is someone supposed to even notice a random error log? At the places that I've worked, trying to make alerting be triggered on only logs was always quite brittle, it's just not best practice. Throw an exception / exit the program if it's something that actually needs fixing!

> If something needs to be fixed, why is it just a log?

What he meant is that is an unexpected condition, that should have never happened, but that did, so it needs to be fixed.

> How is someone supposed to even notice a random error log?

Logs should be monitored.

> At the places that I've worked, trying to make alerting be triggered on only logs was always quite brittle, it's just not best practice.

Because the logs sucked. It not common practice, it should be best practice.

> Throw an exception / exit the program if it's something that actually needs fixing!

I understand the sentiment, but some programs cannot/should not exit. Or you have an error in a subsystem that should not bring down everything.

I completely agree with the approach of the author, but also understand that good logging discipline is rare. I worked in many places where logs sucked, they just dumped stuff, and had to restructure them.

Re: Log level 'error' should mean that something needs to be fixed

#165

Post by Copenjin » Sat, Dec 20, 2025, 9:37 PM UTC

rwmj wrote: post #21

And the second rule is make all your error messages actionable . By that I mean it should tell me what action to take to fix the error (even if that action means hard work, tell me what I have to do).

Exactly. Some applications keep running way after you have long gone. If there is useful information to provide give it.

Re: Log level 'error' should mean that something needs to be fixed

#166

Post by Copenjin » Sat, Dec 20, 2025, 9:39 PM UTC

1123581321 wrote: post #39

rwmj wrote: post #21

And the second rule is make all your error messages actionable . By that I mean it should tell me what action to take to fix the error (even if that action means hard work, tell me what I have to do).

Can you please explain this? That sounds like identifying bugs but not fixing them but I realize you don’t mean that. One hopes the context information in the error will make it actionable when it occurs, never completely successfully, of course.

You can hope that the person reading the context will always able to understand it like you would have. Bad assumption in my experience.

Re: Log level 'error' should mean that something needs to be fixed

#167

Post by Copenjin » Sat, Dec 20, 2025, 9:43 PM UTC

chongli wrote: post #38

rwmj wrote: post #21

And the second rule is make all your error messages actionable . By that I mean it should tell me what action to take to fix the error (even if that action means hard work, tell me what I have to do).

Suppose I'm writing an http server and the error is caused by a flaky power supply causing the disk to lose power when the server attempts to read a file that's been requested. How is the http server supposed to diagnose this or any other hardware fault? Furthermore, why should it even be the http server's responsibility to know about hardware issues at all?

Some of these replies make me wonder if you have ever written any code at all, nonsensical example.

Re: Log level 'error' should mean that something needs to be fixed

#168

Post by mycall » Sat, Dec 20, 2025, 9:54 PM UTC

Severity is the value and you set thresholds based on context of the error type.

Re: Log level 'error' should mean that something needs to be fixed

#169

Post by dpark » Sat, Dec 20, 2025, 9:55 PM UTC

cwillu wrote: post #159

MobiusHorizons wrote: post #122

Earlier quoted context omitted.

What you are proposing sounds like a nightmare to debug. The high level perspective of the operation is of course valuable for determining if an investigation is necessary, but the low level perspective in the library code is almost always where the relevant details are hiding. Not logging these details means you are in the dark about anything your abstractions are hiding from higher level code (which is usually a lo…

Those details don't belong in the error log level, that's what info or trace is for.

They were replying to a person who says “it’s almost always wrong for library functions to log anything”. Not just errors.

Re: Log level 'error' should mean that something needs to be fixed

#170

Post by dpark » Sat, Dec 20, 2025, 9:57 PM UTC

TZubiri wrote: post #140

MobiusHorizons wrote: post #122

Earlier quoted context omitted.

What you are proposing sounds like a nightmare to debug. The high level perspective of the operation is of course valuable for determining if an investigation is necessary, but the low level perspective in the library code is almost always where the relevant details are hiding. Not logging these details means you are in the dark about anything your abstractions are hiding from higher level code (which is usually a lo…

You can log your IO and as long as your functions are idempotent that should be enough info to replicate.

Assuming everything is idempotent is a tall order.

There are a lot of libraries that haven non-idempotent actions. There are a lot of inputs that can be problematic to log, too.