Any Decent Error Message Is a Kind of Oracle
Key topics
The article discusses how well-crafted error messages can serve as a kind of oracle, providing valuable insights into system behavior and aiding in debugging, with commenters sharing their own experiences and strategies for effective error handling.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
6d
Peak period
23
Day 7
Avg / period
12
Based on 24 loaded comments
Key moments
- 01Story posted
Oct 19, 2025 at 7:52 PM EDT
2 months ago
Step 01 - 02First comment
Oct 26, 2025 at 6:51 AM EDT
6d after posting
Step 02 - 03Peak activity
23 comments in Day 7
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 29, 2025 at 3:19 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
generate a random number (e.g. a uuid), log it with the error, and display that number.
doesn't leak data because it's different every time, but you can uniquely pair it up with what they are seeing.
It's like you get to the middle of a recipe and they say to "just" add in the meat you've already been marinating for 48 hours.
Tracing is trivial to add with OTel. It is trivial with Spring Boot (since v3). At least on technical endpoint level. Adding tracing to business logic obviously requires work, but simple propagation is table stakes.
It seems that the parent suggestion is unpopular, but having a technically-available log, with a reference from an entry, seems to be a good compromise. Bit more work for the developer, but less for the user, which is really the goal.
I can tell you exactly why I don't do this, for my app.
I don't want to indicate which of the fields is an issue.
Most folks use Sign up with Apple, though, which obviates this.
The best error message is to avoid the error; either by effective design, or by good affordances.
But this is what WFM. YMMV.
Why not?
Fair bit of work.
The nature of the target demographic demands that I don’t cut any corners, with security.
But I’m also a big proponent of usability, so I would agree, for some applications.
Admins can't log into the frontend (as admins), so hackers can't deduce power user logins from this, or escalate privileges.
That's kind of blasphemy, with the HN crowd, I know, but we aren't interested in selling anything. It's a pure service.
I won't limit retries, because locking users is about as bad as you can get, with userabusability. I just make sure that the fox ain't worth the chase, and make the chase just a bit more difficult, so hackers will waste their time on low-hanging fruit (that tastes pretty bad).
It really seems to be unusual, for folks to limit data collection. I’m always surprised, when folks seem surprised at how little we collect (and we don't actually "collect" the data, as it never leaves the server, and we don't really do anything with the bit we have. It's just enough to give the user a unique ID, and allow other users to anonymously contact them).
It does make administration and forensics a bit more challenging, but that’s our problem; not the user’s.
This ignores the security risks from being too verbose and/or specific with error messages, especially if they’re coming from a server. You’ll usually fail security/pen-test audit.
I agree that doing a better job of helping the user is laudable, but you need to know which battles to fight.
Giving a unique error number that can be referenced by a support team (who could look up the event, look at stack traces, etc.) is the best way to deal with truly exceptional events. Otherwise, if it comes to authentication or authorisation, you have to extremely careful what information you share.
But fair enough, I had stopped at the point where the advice was bad.
My bad. I’ve clarified in my original comment.
In my experience most of those "oopsie woopsie" error messages are an attempt to seem less techie and/or lack of desire to provide meaningful information to the user.
The main thing users really want to know: did they mess up, or did the system mess up? And what should they do next: try again? Contact support? That basic information is not only usually lacking, but providing it to the user would not threaten system security.
The User
They need a coherent explanation of what happened, based on the concepts they can be expected to understand. Ideally enough information/explanation should be provided to allow them to overcome the condition.
The Maintenance
This should be a super detailed description of the error and include any possible context. The user will not reliably preserve this sort of information.
The Attracker
Could they conceivably get access to the data?
Could they get any use out of the data?
Could they cause the error condition that generated the error.