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

Post by jeremyjh » Sun, Dec 21, 2025, 3:02 PM UTC

alex-moon wrote: post #280

jeremyjh wrote: post #277

Earlier quoted context omitted.

There is no "connection string" in mail software that defines the remote host. The other party's MX records do that. If you are sending mail to thousands of remote hosts and one is unreachable, that is NOT a problem a mail administrator is going to be researching or trying to fix because they cannot, and it is not their problem. Either the email address is wrong, the remote host is down, or its DNS is misconfigured.…

OK yeah I think I see what you're saying, if the SMTP mailer is a hosted service and we're talking about the logs for the service itself then failed connections are not an error - this I agree with. I also wouldn't be logging anything transactional at all in this case - the transactional logs are for the user, they are functionality of the service itself in that case, and those logs should absolutely log a failure to…

Post by ninkendo » Sun, Dec 21, 2025, 3:39 PM UTC

layer8 wrote: post #161

Too wrote: post #153

Earlier quoted context omitted.

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 any…

Post by ignoramous » Sun, Dec 21, 2025, 4:08 PM UTC

cogman10 wrote: post #132

Too wrote: post #92

Earlier quoted context omitted.

This is why it’s almost always wrong for library functions to log anything, even on ”errors”. Pass the status up through return values or exceptions. As a library author you have no clue as how an application might use it. Multi threading, retry loops and expected failures will turn what’s a significant event in one context into what’s not even worthy of a debug log in another. No rule without exceptions of course, o…

Depending on the language and logging framework, debug/trace logging can be acceptable in a library. But you have to be extra careful to make sure that it's ultimately a no-op. A common problem in Java is someone will drop a log that looks something like this `log.trace("Doing " + foo + " to " + bar);` The problem is, especially in a hot loop, that throw away string concatenation can ultimately be a performance probl…

  fn trace(log, str, args...) {
     if (!log.tracing) return;
     // ...
  }

Post by [deleted] » Sun, Dec 21, 2025, 4:51 PM UTC

Post by demurgos » Sun, Dec 21, 2025, 6:07 PM UTC

tharkun__ wrote: post #285

demurgos wrote: post #245

Earlier quoted context omitted.

The point of my message is that you should avoid the `log(string)` signature. Even if it's appealing, it's an easy perf trap. There are many ideas if you look at SQL libs. In my example I used a different type but there other solutions. Be creative. logger.log(new Template("foo"))` logger.log("foo", []) logger.prepare("foo").log()

And none of those solve the issue. You pass "foo" to Template. The Template will be instantiated before log ever sees it. You conveniently left out where the Foo string is computed from something that actually need computation. Like both: new Template("doing X to " + thingBeingOperatedOn) new Template("doing " + expensiveDebugThing(thingBeingOperatedOn)) You just complicated everything to get the same class of error.…

    const OPERATION_TIMEOUT = new Template("the operation $operationId timed-out after $duration seconds", {level: "error", code: "E_TIMEOUT"});
    // ...
    function handler(...) {
      // ..
      logger.emit(OPERATION_TIMEOUT, () => ({operationId: "foo", duration: someExpensiveOperationToRetrieveTheDuration()}))
    }