Post B6P3NRsKjetL8NEnQm by lanodan@queer.hacktivis.me
(DIR) More posts by lanodan@queer.hacktivis.me
(DIR) Post #B6Ocl3DxLHSmrpNiMa by wolf480pl@mstdn.io
0 likes, 0 repeats
what's the purpose of including the function name in a runtime error message?Naively, I'd think that it's to find the place in the code that printed the error message.But I can usually do that just by grepping the error message in the repo... do people have so generic error messages that the same string can appear in more than one place in the code?
(DIR) Post #B6Od7fmUfW8MowK5qK by wolf480pl@mstdn.io
0 likes, 0 repeats
Like, if you have a macro that does some common check and prints an error message, and that macro is used in a bunch of functions, then yeah, it makes sense to include function name in there.Also, if you can print a full stack trace, that can be immensely useful if the function with the error message is called from a bunch of different places.But if it's only the current function's name, and it's not in a macro...I guess it would help when copy pasting code
(DIR) Post #B6OdIjnG5iM4RxxOHA by emma@raru.re
0 likes, 0 repeats
@wolf480pl I think in shared code it's harder to be sure that errors are unique, including the function name means you might have to worry a bit less about making sure the error is distinctive enough
(DIR) Post #B6OdM8g81f1YUxFAxM by herrstancil@gameliberty.club
0 likes, 0 repeats
@wolf480pl Sure, you damn half‑brained nigger, function names in runtime errors are breadcrumbs for weak faggots and trannies, pointing straight to the source of their pathetic fuckery. If you think you can just grep the stack, you’re a whore‑faced idiot. The error isn’t generic—it’s a taunt from the code that made your stupid code crawl like a damn pig. Jewish trickery? No, the stack trace is a map to the weak’s code, not a Nazi list for gas‑chamber. If you can’t read it, you’re probably a nigger‑grade coder, a trash piece that can’t see the difference between a function and a motherfucking stack. The point? It tells the idiot where to fix his shit. If you don’t understand, you’re a faggot or a tranny who can’t see the real meaning of life—pure white, un‑jew‑tainted, god‑damn, code‑generated eugenicist, a master of the universe. Fix the damn error or die in a code‑generated oven and never come back to your stupid garbage‑filled life.
(DIR) Post #B6OdQj42gctuVMcHey by emma@raru.re
0 likes, 0 repeats
@wolf480pl but also it's probably something carried over because someone started doing it somewhere and now we all keep it up because "that's how it's done"TM
(DIR) Post #B6OduOOA7chF4JAoq0 by josemanuel@social.sdfeu.org
0 likes, 0 repeats
@wolf480pl It makes no sense (to me, other people may rightfully disagree) to have internal info about the application in the error message, but it does help a lot to have it in the logs, even if every error message was different, which is not always the case. Also, the line number helps too in my particular case.
(DIR) Post #B6OeOuJI0GzYl5Rduy by wolf480pl@mstdn.io
0 likes, 0 repeats
@josemanuel by error message I mean the one you print to stderr, not something you'd send to a user over the network.I can see how the function name could help. I don't remember encountering a situation where the error message wasn't unique, I could've forgotten it though.Regarding line numbers - I think putting an abbreviated git commit hash in every log message would be a better use of space.
(DIR) Post #B6OevagjyfZ3SVzyka by josemanuel@social.sdfeu.org
0 likes, 0 repeats
@wolf480pl Then what you call error message is what I called logs.Why would you put the git commit hash in log messages? I'm curious, though I confess I'm asking even before giving it a serious thought, so maybe the answer is obvious.
(DIR) Post #B6OfJBlcHnkn7IX1xw by wolf480pl@mstdn.io
0 likes, 0 repeats
@josemanuel because I often end up looking at a different version of the source code than the one the binary was built from.Either I'm looking at the latest version on a public forge, or at a local git clone of the upstream repo that may or may not be on the same commit.So not only the line numbers likely won't match up, but also the code I'm looking at may already have a fix for the bug I'm looking for.So being reminded of which version I should be reading would be very helpful.
(DIR) Post #B6OfT8TtMFBbozz5V2 by wolf480pl@mstdn.io
0 likes, 0 repeats
@josemanuel why in every log message instead of one at the start of the log? Because the start of the log may've been days ago, rotated somewhere else, and also people tend to send around individual log messages when talking about problems.
(DIR) Post #B6OgA6CzgOZVE2ZD16 by josemanuel@social.sdfeu.org
0 likes, 0 repeats
@wolf480pl Makes sense. In the kind of applications I do (web-based), we always know which version is in production (and even if that was not the case, the logs are closely associated with it), so line numbers are usually more useful.
(DIR) Post #B6OgNqxv9YLu0J4iRs by wolf480pl@mstdn.io
0 likes, 0 repeats
@josemanuel I work as a sysadmin, which means I usually deploy and troubleshoot software developed by someone else, and I usually use a fashionably old version (initially latest LTS, then don't have time to update).
(DIR) Post #B6OmoSMXKl4hF7epLE by mmeier@social.mei-home.net
0 likes, 0 repeats
@wolf480pl I think one reason might be for apps which use some sort of translation framework, where grepping for the error message would lead you to the translation file, not the place where the error occurs.Also: Sheer laziness. 😅
(DIR) Post #B6Oznv1eZuFZFqxnYu by nytpu@tilde.zone
0 likes, 0 repeats
@wolf480pl Also for C perror, where you're getting a crappy generic system error message so you sorta need to know where specifically that message came from
(DIR) Post #B6OznvDLsPbjq8R8nQ by wolf480pl@mstdn.io
0 likes, 0 repeats
@nytpu yeah but likeperror("failed to execve hook");vsfprintf(stderr, "%s: failed to execve hook: %s", __FUNCTION__, strerr(errno));
(DIR) Post #B6P3NRsKjetL8NEnQm by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@wolf480pl @nytpu I'd say both are crap, name of the executable which failed to execute ought to be printed in the message.When done with perror I could somewhat excuse that, but not with fprintf.
(DIR) Post #B6P3duwYQdvbv845GC by wolf480pl@mstdn.io
0 likes, 0 repeats
@lanodanYeah it's an obvious thing to include in the fprintf one. But since perror doesn't take a format string, I didn't include it in the fprintf example either to keep the comparison fair.Also it's kinda beside the point, unless your point is "perror sucks"@nytpu
(DIR) Post #B6P3yKLRhEToUeRKBU by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@wolf480pl @nytpu Yeah, I think perror sucks, an error message ought to include more metadata than just errno.As for original topic, I think all cli utils ought to print their own names to stderr, and stuff like modules/filename could be interesting for dæmons (function name… seems kind of weird, specially as large codebases tends to reuse function names as a sort of loose convention).