241–250 of 313 posts
Earlier quoted context omitted.
Ideally a logging library should at least not make it easy to make that kind of mistake.
Ideally , but realistically, I have never heard of any major programming language that allows you to express "this function only accepts static constant string literal".
Earlier quoted context omitted.
Ideally a logging library should at least not make it easy to make that kind of mistake.
Ideally , but realistically, I have never heard of any major programming language that allows you to express "this function only accepts static constant string literal".
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…
Earlier quoted context omitted.
If it’s not your code how is a log useful vs returning an error? Even relatively complex operations like say convert this document into a PDF etc basically only has two useful states either it worked or something specific failed at which point just tell me that thing. Now independent software like web servers or database can have useful logs because they have completely independent interfaces with the outside world.…
That’s a very simple operation. Try “take these 100 user generated pdfs and translate all of them”. Oh, “cannot parse unexpected character 0x001?” Cool beans, I wish I knew more.
Any library can do a bad job here, that doesn’t come down to logging vs error messages.
Earlier quoted context omitted.
I feel like there's a parallel with SQL where you want to discourage manual interpolation. Taking inspiration from it may help: you may not fully solve it but there are some API ideas and patterns. A logging framework may have the equivalent of prepared statements. You may also nudge usage where the raw string API is `log.traceRaw(String rawMessage)` while the parametrized one has the nicer naming `log.trace(Template…
You can have 0 parameters and the template is a string...
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()A mail program not being to checks notes send emails sounds like an error to me. (Unless you implement retries.)
> If a SMTP mailer trying to send email to somewhere logs 'cannot contact port 25 on ', that is not an error in the local system and should not be logged at level 'error'. A mail program not being to checks notes send emails sounds like an error to me. (Unless you implement retries.)
Earlier quoted context omitted.
Ideally a logging library should at least not make it easy to make that kind of mistake.
Ideally , but realistically, I have never heard of any major programming language that allows you to express "this function only accepts static constant string literal".
https://typing.python.org/en/latest/spec/literal.html#litera...
I feel like it's more nuanced than OP writes. Presumably every log line comes from something like a try/catch. An edge case was identified, and the code did something differently. Did it do what it was supposed to do, but in a different way or defer for retrying later? Then WARN. Did it fail to do what it needed to do? ERROR Did it do what it needed to do in the normal way because it was totally recoverable? INFO Did…
> Did it fail to do what it needed to do? ERROR
> Did it do what it needed to do in the normal way because it was totally recoverable? INFO
We have a web-facing system (it uses a custom request-response protocol on top of Websocket... it's an old system) that users are routinely trying to, ahem, automate even though it's technically against ToS but hey, as long as we don't catch them? Anyway, it's quite often to see user connections that send malformed commands and then get disconnected after we send them a critical_error/protocol_error message — we do have quite extensive validation logic for user commands.
So, how should such errors be logged in your opinion? I know that we originally logged them as errors but very quickly changed to warnings, and precisely for the reasons outlined in TFA: if some kewl haxxor can't figure out how to quote strings in JSON, it's not really something we can't fix. We probably should keep the records, just to know that "oh, some script kiddie was trying to hack us during that time period" but nothing more than that; it definitely doesn't warrant the "hey, there are too many errors in sfo2 location, please take a look" summons at 3:00 AM from the ops team.