4 ms·

Error: 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

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

mandevil 6mo ago
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.
- landr0id 6mo ago
  Static analysis tools + MCP server + a debugger with an MCP server makes reverse engineering incredibly easy and low-cost. I wrote a blog post about this recently: https://landaire.net/reverse-engineering-with-ai/ https://landaire.net/reverse-engineering-with-ai/ Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.
- vector_spaces 6mo ago
  This is security through obscurity -- can complement other methods but won't do much for you against competent adversaries.
  - pixl97 6mo ago
    Anyone can access the web interface including attackers, so don't dump debug information there. Feel free to put the errors behind an admin interface or to local files that can be retrived.
- EvanAnderson 6mo ago
  > 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. As a sysadmin (having spent 30 years dealing with desktop software) the attitude of the people who gave you that direction make me seethe with anger. Crackers gonna crack. That just hurts the people who have to make the product work in their environment.
arjie 6mo ago
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.
deleted 6mo ago
[deleted]
dec0dedab0de 6mo ago
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.
- ozim 6mo ago
  It depends. If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly. “Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
  - dmd 6mo ago
    I have approximately zero confidence that if I see an error message that says "our support team received the error" that anyone has received the error. In fact I would generally bet thousands of dollars against that.
    - pixl97 6mo ago
      Eh, depends. I very much believe this gets dumped in some kind of ELK stack or something like that. And quite often teams will monitor to ensure that some new error message isn't going wild and alerts are sent out. Single errors mean nothing, unless of course you're putting in a support call and we're directly looking it up.
    - bluGill 6mo ago
      That depends. There are common errors where the support team gets that information because they have seen it before and having seen that error changes the support script in a hopefully helpful way. Companies generally have massive amounts of errors though. They investigate the most common errors for their script. Sometimes when someone figures out a different error they adjust the script. Most errors though never get investigated.
    - protocolture 6mo ago
Insanity 6mo ago
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.
- t-writescode 6mo ago
  Maybe in the UX; but for the love of all things, please shove that data in a user-accessible error log, with enough verbosity that someone could debug it themselves. I am so tired of having to submit a HUGE FUCKING FILE that includes a ton of PII to customer support, only for them to ask the same “did you try uninstalling and reinstalling the app?” (Yes.) afterward.
- deleted 6mo ago
  [deleted]
- 8note 6mo ago
  expected what to be a number? what i have is a string. how do i turn my string into a relevant number?
- setr 6mo ago
  The action on an unhandled / unexpected exception is “please submit this information to your closest administrator” And then dump whatever you want, with a copy button
  - doublerabbit 6mo ago
    Then you find the bug report form was deactivated and the message never being updated. So your now stuck with an error and no where to report it to.
    - rootnod3 6mo ago
      Still better than an error message with pretty much zero info.
hekkle 6mo ago
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.
- magicalhippo 6mo ago
  And all these years I was told security through obscurity wasn't a thing... I work on desktop applications. Tech stack is visible to anyone who can see the error message. If you got a web-based SaaS sure I understand your position, but then you spit all that good stuff into a log and have the error message include the relevant log ids so support can easily find it. If something bad happens while loading a file, include the filename in the logs, and so on.
  - hekkle 6mo ago
    You're right, this is more for web applications than for desktop applications.
nazgul17 6mo ago
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.
superjan 6mo ago
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.
frevib 6mo ago
To the user: friendly message with uuid. In the logs: detailed technical message with uuid.

mandevil 6mo ago

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.

landr0id 6mo ago
Static analysis tools + MCP server + a debugger with an MCP server makes reverse engineering incredibly easy and low-cost. I wrote a blog post about this recently: https://landaire.net/reverse-engineering-with-ai/ https://landaire.net/reverse-engineering-with-ai/ Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.
vector_spaces 6mo ago
This is security through obscurity -- can complement other methods but won't do much for you against competent adversaries.
- pixl97 6mo ago
  Anyone can access the web interface including attackers, so don't dump debug information there. Feel free to put the errors behind an admin interface or to local files that can be retrived.
EvanAnderson 6mo ago
> 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. As a sysadmin (having spent 30 years dealing with desktop software) the attitude of the people who gave you that direction make me seethe with anger. Crackers gonna crack. That just hurts the people who have to make the product work in their environment.

arjie 6mo ago

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.

deleted 6mo ago

[deleted]

dec0dedab0de 6mo ago

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.

ozim 6mo ago
It depends. If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly. “Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
- dmd 6mo ago
  I have approximately zero confidence that if I see an error message that says "our support team received the error" that anyone has received the error. In fact I would generally bet thousands of dollars against that.
  - pixl97 6mo ago
    Eh, depends. I very much believe this gets dumped in some kind of ELK stack or something like that. And quite often teams will monitor to ensure that some new error message isn't going wild and alerts are sent out. Single errors mean nothing, unless of course you're putting in a support call and we're directly looking it up.
  - bluGill 6mo ago
    That depends. There are common errors where the support team gets that information because they have seen it before and having seen that error changes the support script in a hopefully helpful way. Companies generally have massive amounts of errors though. They investigate the most common errors for their script. Sometimes when someone figures out a different error they adjust the script. Most errors though never get investigated.
  - protocolture 6mo ago

Insanity 6mo ago

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.

t-writescode 6mo ago
Maybe in the UX; but for the love of all things, please shove that data in a user-accessible error log, with enough verbosity that someone could debug it themselves. I am so tired of having to submit a HUGE FUCKING FILE that includes a ton of PII to customer support, only for them to ask the same “did you try uninstalling and reinstalling the app?” (Yes.) afterward.
deleted 6mo ago
[deleted]
8note 6mo ago
expected what to be a number? what i have is a string. how do i turn my string into a relevant number?
setr 6mo ago
The action on an unhandled / unexpected exception is “please submit this information to your closest administrator” And then dump whatever you want, with a copy button
- doublerabbit 6mo ago
  Then you find the bug report form was deactivated and the message never being updated. So your now stuck with an error and no where to report it to.
  - rootnod3 6mo ago
    Still better than an error message with pretty much zero info.

hekkle 6mo ago

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.

magicalhippo 6mo ago
And all these years I was told security through obscurity wasn't a thing... I work on desktop applications. Tech stack is visible to anyone who can see the error message. If you got a web-based SaaS sure I understand your position, but then you spit all that good stuff into a log and have the error message include the relevant log ids so support can easily find it. If something bad happens while loading a file, include the filename in the logs, and so on.
- hekkle 6mo ago
  You're right, this is more for web applications than for desktop applications.

nazgul17 6mo ago

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.

superjan 6mo ago

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.

frevib 6mo ago

To the user: friendly message with uuid. In the logs: detailed technical message with uuid.