alt Hacker NewsError: File not found
Which file?!?!?!
Anyway, I disagree strongly on the technical jargon. Ok, if it's not really an error and the user can retry or similar sure.
But if it's bad times, an exception or similar, don't care about the user. Instead include as much detail as you need. A non-technical user won't be able to do anything anyway, and a sanitized error message means support or a technical user has a much harder time figuring out what the real issue might be, in order to work around it.
Failed to load a shared library? State the filename and exact error code and message, and anything else that might be useful. And so on.
Replies
I’ve learned this lesson over the years. It is quite common that users make a screenshot of the error with their phone, and send it on to support with hardly any details. The fact that errors become recognizably different is also an improvement: the user and support staffer can recognize recurring errors, and notice patterns.
Agreed, but you can have both. A simple error for the user to understand, and a click for more details that spits out all the troubleshooting information.
Depends on exactly the situation- when I worked on a very expensive desktop application years ago I was warned about giving too much information in error messages as it might help crackers.
With how powerful Ghidra is now, I'm not sure that it matters much any more.
I've done this to myself because I was too lazy to write the `fmt!()` instead of the raw string while I was iterating and then just forgot to fix it later. I think the Go logger's default of accepting chained parameters that it logs by default to JSONL worked well to avoid that. Convenient ergonomics just in time (in the cosmic sense of programming) for it all to be irrelevant because an LLM always puts it in the error string.
As someone who is a penetration tester, I can assure you that this is a TERRIBLE idea. Look up "CWE-200". While you are correct that this might help someone fix an issue, I can assure you it will help MANY more people to understand the technology stack you are working with and allow them to exploit unpatched vulnerabilities in your tech stack.
You can have both of you provide an error code that your support team can look up in the logs to find the complete error message.
To the user: friendly message with uuid.
In the logs: detailed technical message with uuid.
IMO if you show an error to end users it needs to be actionable. Tell them what to do instead (e.g retry or wait, use other input file, etc etc).
So don't say "InvalidArgumentException xyz", say "Expected a number but got 'hello'".
This doesn't always work, but essentially hide tech details from users. If you must, include a bit of extra information (a request number or whatever) that helps you log dive.