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
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.
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.
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.
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.