Hacker News Reader

Comment by magicalhippo | Hacker News Reader

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.

View on HN

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.

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.

expected what to be a number?

what i have is a string. how do i turn my string into a relevant number?

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

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.

Still better than an error message with pretty much zero info.

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.

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/

Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.

This is security through obscurity -- can complement other methods but won't do much for you against competent adversaries.

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.

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

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.

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.

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.

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.

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.

I have seen the mailboxe folderss of companies with automated error responses and none of them were read.

The only place I've worked that logged out technical details (inside of a <details> element) was also the one that did the best with logging those in Bugsnag and then having engineers triage them and create tickets. I think those things are very connected.

> “our support team received the error”

Oh good, I guess I’ll expect to hear back never.

I think it’s a good thought but we’ve been conditioned that these things are black holes. User should have all agency in escalating or continuing troubleshooting rather than implied wait for deus ex machina from the support team.

> If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user.

What support team? The ones that were all not hired in the first place, and if they were hired then they were replaced by AI? The same support team that customers simply cannot reach at all?

Sounds very useful.

Not everyone is Google, Meta, Amazon or Microsoft.

There are companies that care about their customers.

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.

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.

You're right, this is more for web applications than for desktop applications.

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.

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.

Reply on news.ycombinator.com